Private token should not be made available on the client side

Your private_token is currently available through gon.api_token which:

it’s as though my password is displayed...

--Stan

AFAIK private_tokens should never be available on the client side as they are the same as passwords.

cc @DouweM @rspeicher @stanhu @dzaporozhets

I think we also use this token for the RSS feed, which is understandable if you're trying to load from an external program, but it always made me nervous when I saw it in the URL.

@stanhu Correct.

@stanhu @rspeicher I agree we should not render it on client side. At least encrypt it with some session token or something. According to RSS url - maybe generate special read-only token that can't be used anywhere else except RSS

@connorshea Pointed out these API calls aren't really needed. Encrypting the RSS still makes sense but these calls shouldn't need to use the API, they can just use the rails application that rendered it which I believe is currently how the dropdowns work and is how the new AJAX todos work.

mentioned in issue #18535 (closed)

Reassigned to @lbennett

So looking into this, it's probably best to keep the API class in place and just swap out what it has configured as its API paths to the rails application routes.

This may take some time until its merged as some of the view controllers do not provide JSON. It also seems the /namespaces, /licenses and /gitignores are only available to from HTTP API?

Assignee removed

@lbennett the licenses and gitignore endpoints need no authentication, they're public. I don't think private tokens are passed to them (or they shouldn't be, anyway).

@connorshea Awesome, thanks. :)

Reassigned to @lbennett

Removed frontend ~13884 ~14106 labels

Milestone changed to %8.10

I think whilst doing this all current AJAX calls that aren't going through api.js.coffee should be refactored to ensure DRYness. Is this within the scope @DouweM @jschatz1? I wanted to open this as a new issue but didn't want to bring any attention to api.js.coffee because of this issue.

Also, if we've highlighted this as an issue, would it be wise to open up an issue to add a layer of authentication before you can even view your private token in the settings?

@lbennett api.js.coffee should just be used for accessing the GitLab API. If we want to get rid of private_token (which makes sense), the only thing that would still use the GitLab API is getting templates, since everything else requires authentication. So I'd say we'd be moving away from api.js.coffee, not toward it?

It should probably not be called api.js.coffee (we will keep this file for endpoints that only exist in the API and do not require private token), but I think it would still be useful to DRY the non-API AJAX requests, maybe a routes.js.coffee file but that is equally as incorrect a name I suppose.

@godfat offered an interesting suggestion on Slack that would allow us to use the rails session with the API.

What I said on Slack was:

i agree that we shouldn't use private_token because it never expires. personally i would prefer to use cookie/session as in rails to authenticate for the API. i used to do this a lot, even in cross domain. (i.e. cookie was set for .domain.com and we access it from www.domain.com and api.domain.com)

Previously I always try to make the API access the same session/cookie as in the web application, so that we could use the same way for auth. Frankly I really don't understand why people would want to use token for auth. If we roll our own token, we need to take care about a lot of security concerns. With cookie, browsers would already do a lot of protection for us. Unless we're talking about totally different domains...

Milestone changed to %8.11

Added ~14106 technical debt labels

Assignee removed

I will definitely set this as a priority after I get past my current load, unassigned incase anyone else wants to do the deed in the meantime.

Added ~480950 and removed ~14106 technical debt labels

Added ~14106 technical debt labels

Milestone changed to %8.12

Reassigned to @lbennett

Seeing as it took me a couple hours to work out how to refactor just one of the endpoints and the next one was even more confusing, it's safe to say this goes waaaaaaaaaaaaaaaaaaay over my head, sorry guys.

These all need to be converted to actions:

groupsPath: "/api/:version/groups.json",
groupPath: "/api/:version/groups/:id.json",
namespacesPath: "/api/:version/namespaces.json",
groupProjectsPath: "/api/:version/groups/:id/projects.json",
projectsPath: "/api/:version/projects.json?simple=true",
labelsPath: "/api/:version/projects/:id/labels",
licensePath: "/api/:version/licenses/:key",
gitignorePath: "/api/:version/gitignores/:key",
ldapGroupsPath: "/api/:version/ldap/:provider/groups.json",
gitlabCiYmlPath: "/api/:version/gitlab_ci_ymls/:key"

I'm still happy to implement these on the frontend as I'd like to refactor the Api object literal, I'll stay subscribed.

/cc @DouweM

Assignee removed

I'd also like to implement the tests for this once complete as api.js has one of the poorest coverages.

Reassigned to @nick.thomas

This looks right up my alley, I'll see what I can do.

@godfat using the rails cookie for api auth is the sensible way to do this, I think, so i'll explore that first. Certainly the smallest diff!

I'm excited! :party_parrot:

I guess this WIP needs to go to dev.gitlab.org ?

@nick.thomas Yah!

https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/1995

(don't get excited, it's nothing interesting yet)

@nick.thomas Thanks for taking this on!

Mentioned in commit bec0c455

Status changed to closed by commit ba7c3685

Made the issue visible

Mentioned in commit ba7c3685

Mentioned in issue #22450 (closed)

Mentioned in issue #22435 (closed)

Made the issue confidential

Made the issue visible

Mentioned in issue #22537 (closed)

mentioned in commit tczzjin/gitlab-ce@8ddfeec8

mentioned in merge request !14785