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

Umbrella REST API "POST /api-umbrella/v1/users" fails with Umbrella 0.11 #217

Closed
jykae opened this issue Feb 11, 2016 · 11 comments
Closed
Milestone

Comments

@jykae
Copy link

jykae commented Feb 11, 2016

We are using Umbrella Admin API in https://github.com/apinf/api-umbrella-dashboard project.

POST data sent:

{ 
  "user": {
     "email":  "test.user@email.com",
     "first_name": "-",
     "last_name": "-",
     "terms_and_conditions": true 
}

Everything else works with Umbrella Admin API, but creating user fails with 403 Forbidden:

{
  "error": {
    "code": "API_KEY_UNAUTHORIZED",
    "message": "The api_key supplied is not authorized to access the given service. Contact us at https://nightly.umbrella.apinf.io/contact/ for assistance"
  }
}
@jykae
Copy link
Author

jykae commented Feb 11, 2016

I used the same email address for generating API Key that I have in my admin account.

@jykae
Copy link
Author

jykae commented Feb 11, 2016

Tried using API key that Umbrella uses for "internal Ajax requests", that works. Did not change my admin auth token.
Normal API key doesn't work for creating user. There seems to be no relation with email address like we thought.

Is there possibility to give normal API key rights to create user, so we could have own API key for our api-umbrella-dashboard?

@GUI
Copy link
Member

GUI commented Feb 11, 2016

The API key you use to create other API keys will need to have the api-umbrella-key-creator role assigned to it. If you assign that role to the key in the admin and save, then I think you should fix the 403 forbidden issues. However, if that doesn't do the trick, let us know.

If that does work, though, I'd be interested: Is the key you're using one that you previously were able to create API keys with before the API Umbrella upgrade? This role requirement should have always been in place, but if that role requirement wasn't actually functioning as intended under your previous installation, I want to be sure we flag that as an upgrade compatibility note.

@jykae
Copy link
Author

jykae commented Feb 11, 2016

Thank you for the answer.

This installation is fresh installation of Umbrella v0.11 to be used just for our nightly builds of api-umbrella-dashboard. I will try the first trick, and let you know if it works.

@jykae
Copy link
Author

jykae commented Feb 11, 2016

That did the trick, thanks.

@jykae jykae closed this as completed Feb 11, 2016
@jykae jykae reopened this Feb 12, 2016
@brylie
Copy link
Contributor

brylie commented Feb 12, 2016

@GUI, thanks for the quick response and support.

The underlying issue here, having to assign superuser accounts with an additional api-umbrella-key-creator role, may be a regression. I.e. in 0.8, and semantically (see below), superuser accounts have all permissions.

superuser account is capable of unrestricted, potentially adverse, system-wide changes. (Wikipedia)

@jykae
Copy link
Author

jykae commented Feb 12, 2016

Just a note here for @GUI Today we successfully upgraded from v0.8 -> v0.11

Steps I needed to do after "sudo apt-get api-umbrella upgrade":

@brylie
Copy link
Contributor

brylie commented Feb 23, 2016

This issue is affecting our development team and our API Umbrella integration on our nightly deployment.

When setting up a development environment for new developers, we added the required permissions to their API User account, but were unable to launch the application. Also, on our nightly deployment server, we cannot create new users.

In both cases, there is an API call being made to the Admin API. Our integration code has not changed recently, but the API Umbrella version has been upgraded on the staging server.

@brylie
Copy link
Contributor

brylie commented Feb 23, 2016

On our project issue tracker, I posted steps to reproduce. This affects both our 0.8 -> 0.11 upgrade server as well as a fresh 0.11 instance.

Steps to reproduce

  1. Log in to API Umbrella (0.11 @ nightly.umbrella.apinf.io)
  2. Go to Users -> Admin Accounts
  3. Create a new admin user
    • check 'superuser' box
  4. Go to Users -> API Users
  5. Click 'Add New API User'
  6. Create new API user with same email as admin user
    • Under Permissions -> Roles, add api-umbrella-key-creator
  7. Sign-in with new Admin user
  8. Get API Key and Admin API Token for new user
  9. Add API Key and Admin API Token to settings.json
  10. Launch Apinf
  11. Register a new user

Observed behavior

When registering a new user, the screen displays an Internal server error message. In the server console, the following error appears:

Exception while invoking method 'ATCreateUserServer' Error
     at new ApiUmbrellaError (packages/brylie_api-umbrella/server/apiUmbrellaError.js:33:1)
     at Object.self.adminApi.v1.apiUsers.createUser (packages/brylie_api-umbrella/server/apiUmbrellaWeb.js:275:1)
   ...

The main issue is related to the following line Object.self.adminApi.v1.apiUsers.createUser (packages/brylie_api-umbrella/server/apiUmbrellaWeb.js:275:1, where we are trying to create an user on API Umbrella. FWIW, that part of our integration code hasn't changed since 12 November 2015.

@GUI
Copy link
Member

GUI commented Mar 1, 2016

@brylie: Sorry for the delay. You're right that I think this is a regression when an admin account is being used. That wasn't a scenario we were explicitly testing for, but I think you're right that an admin account should be able to create users regardless of the roles associated with their API key. We'll try to get that fixed this week along with adding test coverage for this scenario.

If you're looking for a quick fix, I believe you could temporarily work around it by editing the /opt/api-umbrella/embedded/apps/core/current/config/default.yml file and removing lines 300-302.

GUI added a commit that referenced this issue Mar 8, 2016
The admin tokens take precedence over the role requirements for
accessing the API endpoint to create new api keys.

See #217
@GUI
Copy link
Member

GUI commented Mar 8, 2016

Resolved in 0cd7b88 Apologies for the regression, but thanks for letting us know. We now have better test coverage around this specific behavior.

We'll probably try to get v0.11.1 packages released early next week that will include this patch along with a few other bug fixes.

@GUI GUI added this to the v0.11.1 milestone Mar 8, 2016
@GUI GUI closed this as completed Jun 26, 2016
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

No branches or pull requests

3 participants