New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve API onboarding #2240

mapkyca opened this Issue Oct 22, 2018 · 4 comments


None yet
2 participants
Copy link

mapkyca commented Oct 22, 2018

While trying to do this:

Use an API based client

I encountered this error:

I have to use the api key for the user - fine - however getting this is non-intuitive for regular folk, who will almost certainly expect standard username/password.

We should probably have a mechanism to exchange a username/password for a key... although this is in essence the same thing, so perhaps we should do away with the api key system altogether... see #831 (keys are basically passwords)

Some other notes:

Give us some context:

  • It'd also be really handy if you could tell us the contents of your version.known file
  • What database are you using? (e.g. mongo, mysql, postgres)
  • Any warnings or errors in your admin/diagnostics page?
  • Bonus points - are you able to illustrate the issue with a unit test? If so, submit it as a pull request!

This comment has been minimized.

Copy link
Collaborator Author

mapkyca commented Dec 6, 2018

The obvious way would be to somehow get a token from a username/password, which might be to use a form/token post on the login and retrieve a token. This proves difficult, owing to the session id portion in the token generation.

I'm thinking OAuth is probably the way to go


This comment has been minimized.

Copy link

physcocode commented Dec 7, 2018

Oauth 2.0 is the answer here , for all user who want to authenticate with username and password can do so using the password grant type . I would definitely suggest using inside known core for getting up and running 2.0 server in no time .
If someone wants to authenticate with standard token they can always use the implicit grant type 💯


This comment has been minimized.

Copy link
Collaborator Author

mapkyca commented Dec 7, 2018

I agree. Personally, I'd like to move api over to OAuth2.0, although this may require a bit of discussion. The current API has a number of issues which OAuth2 would go a long way to solving.

Actually wrote a Known plugin that does this some time back, so it may be worth adopting that and cleaning off the bitrot.

@benwerd, what are your thoughts?


This comment has been minimized.

Copy link
Collaborator Author

mapkyca commented Jan 15, 2019

Hmm... OAuth is only part of the story.

The issue is that if a client wants to connect, it needs to know what client app to talk to. Fine for a central service, not so much for self hosted installs.

The out of the box OAuth2 process needs some tweaks to the workflow to solve this issue...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment