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

Normalize API error responses #1437

Open
vitoravelino opened this Issue Sep 27, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@vitoravelino
Member

vitoravelino commented Sep 27, 2017

Currently we have the following formats:

// grape validation (400)
{"errors" => {"[\"name\"]" => ["is missing"]}}

// team creation (422)
{"errors" => ["Name can't be blank"]}

// authorization (403)
{"errors" => "Authorization fails"}

We need to make the values more consistent.

mssola added a commit to mssola/Portus that referenced this issue Feb 14, 2018

api: added a bootstrap endpoint
This new endpoint lives inside of the user namespace and its main goal is to
allow people to create the first admin user from the API. This endpoint is only
allowed if the `first_user_admin` option has not been disabled. Another
restriction is that there shouldn't be a user already created. Last but not
least, this method can be called without being authenticated.

In the ideal case, you would call this method when you just started your Portus
instance. Then, you will get the first user created
(same arguments as `POST /api/v1/users`) and it will also get an application
token assigned to it. The reponse will be the `plain_token` from the application
token. Thus, the whole point of this method is to follow this workflow:

1. Portus instance deployed.
2. Admin uses this bootstrap endpoint to create the admin user and get an
   application token.
3. With this application token the admin starts to administrate the
   instance (e.g. register the registry on Portus) entirely from the API.
4. Admin makes the Portus instance available inside of the organization and
   starts structuring it inside of Portus.

Finally, this commit also started to make error responses more uniform. This was
firstly done to DRY some of the code created by this feature. It probably needs
more work (see SUSE#1437).

See SUSE#1412

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>

mssola added a commit to mssola/Portus that referenced this issue Feb 14, 2018

api: added a bootstrap endpoint
This new endpoint lives inside of the user namespace and its main goal is to
allow people to create the first admin user from the API. This endpoint is only
allowed if the `first_user_admin` option has not been disabled. Another
restriction is that there shouldn't be a user already created. Last but not
least, this method can be called without being authenticated.

In the ideal case, you would call this method when you just started your Portus
instance. Then, you will get the first user created
(same arguments as `POST /api/v1/users`) and it will also get an application
token assigned to it. The reponse will be the `plain_token` from the application
token. Thus, the whole point of this method is to follow this workflow:

1. Portus instance deployed.
2. Admin uses this bootstrap endpoint to create the admin user and get an
   application token.
3. With this application token the admin starts to administrate the
   instance (e.g. register the registry on Portus) entirely from the API.
4. Admin makes the Portus instance available inside of the organization and
   starts structuring it inside of Portus.

Finally, this commit also started to make error responses more uniform. This was
firstly done to DRY some of the code created by this feature. It probably needs
more work (see SUSE#1437).

See SUSE#1412

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>

mssola added a commit to mssola/Portus that referenced this issue Mar 14, 2018

api: added a bootstrap endpoint
This new endpoint lives inside of the user namespace and its main goal is to
allow people to create the first admin user from the API. This endpoint is only
allowed if the `first_user_admin` option has not been disabled. Another
restriction is that there shouldn't be a user already created. Last but not
least, this method can be called without being authenticated.

In the ideal case, you would call this method when you just started your Portus
instance. Then, you will get the first user created
(same arguments as `POST /api/v1/users`) and it will also get an application
token assigned to it. The reponse will be the `plain_token` from the application
token. Thus, the whole point of this method is to follow this workflow:

1. Portus instance deployed.
2. Admin uses this bootstrap endpoint to create the admin user and get an
   application token.
3. With this application token the admin starts to administrate the
   instance (e.g. register the registry on Portus) entirely from the API.
4. Admin makes the Portus instance available inside of the organization and
   starts structuring it inside of Portus.

Finally, this commit also started to make error responses more uniform. This was
firstly done to DRY some of the code created by this feature. It probably needs
more work (see SUSE#1437).

See SUSE#1412

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>

mssola added a commit to mssola/Portus that referenced this issue Mar 15, 2018

api: added a bootstrap endpoint
This new endpoint lives inside of the user namespace and its main goal is to
allow people to create the first admin user from the API. This endpoint is only
allowed if the `first_user_admin` option has not been disabled. Another
restriction is that there shouldn't be a user already created. Last but not
least, this method can be called without being authenticated.

In the ideal case, you would call this method when you just started your Portus
instance. Then, you will get the first user created
(same arguments as `POST /api/v1/users`) and it will also get an application
token assigned to it. The reponse will be the `plain_token` from the application
token. Thus, the whole point of this method is to follow this workflow:

1. Portus instance deployed.
2. Admin uses this bootstrap endpoint to create the admin user and get an
   application token.
3. With this application token the admin starts to administrate the
   instance (e.g. register the registry on Portus) entirely from the API.
4. Admin makes the Portus instance available inside of the organization and
   starts structuring it inside of Portus.

Finally, this commit also started to make error responses more uniform. This was
firstly done to DRY some of the code created by this feature. It probably needs
more work (see SUSE#1437).

See SUSE#1412

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment