-
Notifications
You must be signed in to change notification settings - Fork 325
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
Comments
I used the same email address for generating API Key that I have in my admin account. |
Tried using API key that Umbrella uses for "internal Ajax requests", that works. Did not change my admin auth token. Is there possibility to give normal API key rights to create user, so we could have own API key for our api-umbrella-dashboard? |
The API key you use to create other API keys will need to have the 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. |
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. |
That did the trick, thanks. |
@GUI, thanks for the quick response and support. The underlying issue here, having to assign superuser accounts with an additional
|
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":
|
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. |
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
Observed behaviorWhen 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 |
@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 |
The admin tokens take precedence over the role requirements for accessing the API endpoint to create new api keys. See #217
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. |
We are using Umbrella Admin API in https://github.com/apinf/api-umbrella-dashboard project.
POST data sent:
Everything else works with Umbrella Admin API, but creating user fails with 403 Forbidden:
The text was updated successfully, but these errors were encountered: