Skip to content
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

Adds Personal Access Tokens for API access (fixes #541) #1075

Merged
merged 27 commits into from
May 29, 2019

Conversation

andrewn
Copy link
Member

@andrewn andrewn commented May 14, 2019

Implements Personal Access Tokens for API access. This builds on top of the excellent work in #731 to allow access tokens to be created by users and used to authenticate instead of a password.

I plan on making the following changes from #731:

  • Move token generation to the server-side from the client. This seems to be how other providers do this (Digital Ocean, Github, Harvest).
  • Displays tokens as part of Account page (moving from the Advanced page)
  • Write UserController tests for creating/deleting keys
  • Improve display of tokens in UI
  • Write UI tests <- I'll do these in a future PR

I have verified that this pull request:

  • has no linting errors (npm run lint)
  • is from a uniquely-named feature branch and has been rebased on top of the latest master. (If I was asked to make more changes, I have made sure to rebase onto master then too)
  • is descriptively named and links to an issue number, i.e. Fixes #123

UI

I've added tabs to the Account screen. The Access Tokens tab allow tokens to be created and deleted.

User interface for managing Access Tokens

Automated testing

I've written tests for the controller endpoints but created Mongoose model mocks by hand. This isn't ideal so I'd like to re-visit these in a future PR once we've figured out a good way forward for testing.

Manual test plan

  1. Create a new access token at /account
  2. Copy access token and use curl to access the test endpoint:
    curl -X GET --user <username>:<access-token> -i localhost:8000/api/auth/access-check
    If successful, the user's session data should be returned and Last used time in UI should update.
  3. Change username, access should be forbidden
  4. Change token, access should be forbidden
  5. Delete token via UI
  6. API access should be forbidden

@andrewn andrewn changed the title [WIP] Adds Personal Access Tokens for API access (fixes ##541) [WIP] Adds Personal Access Tokens for API access (fixes #541) May 14, 2019
@andrewn andrewn changed the title [WIP] Adds Personal Access Tokens for API access (fixes #541) Adds Personal Access Tokens for API access (fixes #541) May 15, 2019
@andrewn andrewn marked this pull request as ready for review May 15, 2019 14:35
}

tbody tr:nth-child(odd) {
background-color: #f2f2f2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could this use a color in the theme map rather than a raw color value?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The account page doesn't respect the theme, but it probably should?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I've started work on this in #1080.

@catarak
Copy link
Member

catarak commented May 21, 2019

Some other stuff I noticed:

  • I created a new account, and then immediately opened "Settings -> API Tokens" and the application crashed. It worked totally fine after I refreshed the page.
  • Extremely small UI fix, could use some space between these two elements (same as the form labels/inputs):

Screen Shot 2019-05-21 at 4 47 48 PM

  • Just... thinking about the overall design of this page. The border for the tabs feels a little funky, though I'm not sure how to change it.

@catarak
Copy link
Member

catarak commented May 21, 2019

but i ran through your test plan and it's working for me!

@andrewn andrewn mentioned this pull request May 22, 2019
8 tasks
@andrewn
Copy link
Member Author

andrewn commented May 22, 2019

  • Just... thinking about the overall design of this page. The border for the tabs feels a little funky, though I'm not sure how to change it.

I know, I'm not very happy with the layout of the page. There's a design for it in #392 but I'm not convinced that it improves things much as none of the fields look editable.

The tabs here don't really work in the full-width page, but we could adopt a side-navigation like GitHub does?

Screenshot 2019-05-22 11 22 45

This is until this page's components are made theme-aware
There's duplication in the user and session endpoints that
all return the same shaped user model data. The new helper should keep
them consistent when new properties need to be exposed.
@andrewn
Copy link
Member Author

andrewn commented May 22, 2019

@catarak, I made those fixes so this is ready for a re-review.

  • I created a new account, and then immediately opened "Settings -> API Tokens" and the application crashed. It worked totally fine after I refreshed the page.

I fixed this in 5777be3 by ensuring the API consistently returns apiKeys in the user-shaped response.

  • Extremely small UI fix, could use some space between these two elements (same as the form labels/inputs)

Added some padding around the button.

@catarak
Copy link
Member

catarak commented May 22, 2019

I was just thinking about merging this to master and then this being available in production—maybe it makes sense to merge it to another branch until this is built out more? Maybe it could be visible by a secret url or something? It's hard since this project doesn't have a staging deployment, though it could!

@catarak
Copy link
Member

catarak commented May 22, 2019

one option for the design, that would keep the tabs at the top, would be to wrap the settings container in a box (e.g. like the login design here) so that the tab strip wouldn't be floating.

@andrewn andrewn changed the base branch from master to feature/public-api May 23, 2019 09:48
@andrewn
Copy link
Member Author

andrewn commented May 23, 2019

I was just thinking about merging this to master and then this being available in production—maybe it makes sense to merge it to another branch until this is built out more? Maybe it could be visible by a secret url or something? It's hard since this project doesn't have a staging deployment, though it could!

That's a very good point. I've created a new branch feature/public-api for this purpose and changed the base branch of this PR.

I'll create a new PR for merging feature/public-api into master and use that to track the status of the API work.

It'd be great to have a deployment of this branch for testing. How much effort is that do you think?

Alternatively, we could deploy to production and hide behind feature flags.

@catarak
Copy link
Member

catarak commented May 23, 2019

It'd be great to have a deployment of this branch for testing. How much effort is that do you think?

I think, with the power of CI/CD and Kubernetes, it's not too hard. What I'd need to do:

  • add staging_deploy script/task to Travis, which will be extremely similar to deploy.sh
  • update Kubernetes cluster config with new deployment/namespace for staging
  • add new repository on Dockerhub for staging image
  • add these variables to Travis

I might wait to start on this until we merge in your .travis.yml changes, so we don't have to deal with conflicts there.

@andrewn
Copy link
Member Author

andrewn commented May 27, 2019

Now that #1081 is merged, this is ready too. 👍

@catarak
Copy link
Member

catarak commented May 28, 2019

Now that #1081 is merged, this is ready too. 👍

great, i can work on setting up the staging deployment this week!

@catarak catarak merged commit 7c4f180 into processing:feature/public-api May 29, 2019
@andrewn andrewn deleted the generate-api-keys branch June 4, 2019 10:37
@trych
Copy link

trych commented Nov 8, 2020

Whatever happened to the API access features? Is there any plan to implement them?
The public-api branch doesn't seem to exist anymore?

@catarak
Copy link
Member

catarak commented Nov 9, 2020

@trych the API has been implemented but it hasn't been released yet, but there are plans for this soon. Stay tuned :)

@trych
Copy link

trych commented Dec 12, 2020

@catarak

One more question regarding the API:
I want to include some sketches in a blog-like article via the embed feature, so I am dealing with iframes. I am having trouble to automatically get the height of my sketch, as this is of course a cross-origin scenario, so I cannot read the canvas' height via JS.

Is this something that could/would be solved by the API? As in: I would be able to access the sketch height via the API? Or are there even any other solutions for that, that I am missing?

(I could also open a separate issue for that, if that helps)

@catarak
Copy link
Member

catarak commented Dec 14, 2020

@trych great question! I think this is a separate issue, so I'm going to open one and answer your question there 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants