Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

Normalize API error responses #1437

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

Normalize API error responses #1437

vitoravelino opened this issue Sep 27, 2017 · 0 comments

Comments

@vitoravelino
Copy link
Contributor

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
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
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
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
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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant