sedovalx / oauth2-tester Goto Github PK

Now it is a JSON in the <pre> tag. But it should be possible to create a markup for
Request:

• method
• uri
• query parameters
• headers (optional)
• body (optional)

Response:

• status
• protocol version
• headers (optional)
• content type (from headers)
• body (optional)

Error:

• message
• error type
• error message

Flow types should be declared on the backend. It should return them on request. On the other hand frontend should keep the current flow type in the local state and give a user a posibility to select a flow type from the setting dialog.

It should be possible to

• List all saved servers info (names).
• Add new server info: name, authorization and token endpoints, client id and secret.
• Edit server info
• Add new server

Server identity is his name. Should be single save server operation for editing and adding.

Client application should has a 'callback' route for accepting the code in the uri query params.

• Find out the target server. From the document.referrer?
• The code should be saved in the client's server info.
• Button for run the exchanage code for token command should be enabled

When the client do the auth request via the server it should await the token in the response body:

{
  response: {
    body: {\"access_token\":\"35a70395cea0670c15373e8a05e1e977b3aff913\",\"token_type\":\"bearer\",\"scope\":\"user\"}"
  }
}

When a user are browsing the servers the suggested uri should be built. It should depends on

• current server
• current flow type
• presence of the token for the server
• presence of a auth code for the server
• username/password

User should be able to edit the suggested request in the request editor.

If the client application on the startup finds the auth code and the state in the URI it should try to restore previous request from the local storage and build request/response.

Должна уметь сохранять следующие поля:

• Client ID строка
• Client Secret строка
• Authorization endpoint строка
• Token endpoint строка

Какой-либо привязке к текущему пользователю наверное не нужно.
Возможно потом привязать историю запросов.

Backend should has the base route for handling callback errors. Important point: the registered callback address should be the base address for auth code callback and for the token callback.

• GET /callback?code= - redirect to the frontend (payload: code & referrer?)
• GET /callback?error= - redirect to the frontend (payload: error & referrer?)
• GET /callback?access_token= - should complete the frondend "exchangeAuthCode" request #7 with token
• POST /callback + { access_token } - should complete the frondend "exchangeAuthCode" request #7 with error
• POST /callback + { error } - should complete the frondend "exchangeAuthCode" request #7 with error

Each server can has a code and token. But for now it only possible to store just one that is parsed from the uri at the app start. Application should find proper server and store the code and token in it.

It should be possible to edit any outgoing request ala Postman.

It comes not as a query parameter but as a hash value in the URI. AppContainer should look for it on the start up.

Front end should

• request backend with server name and flow type
• get auth uri
• navigate to this uri

Backend should build auth uri based on the flow type.

Cannot read property 'addEventListener' of null happens when user removes a query param from the uri. It leads to rerender of the KeyValueList without this param. After that error happens...

Should be a backand controller for executing client requests to an Internet resource. The controller should proxy client requests with preserving headers, body, method and uri of the original request. It should return the original request and the response object to the client. We need to define data contract for such a response:

• response object
• request object
• possible error while trying to execute the request (network and etc.)

Front end should call backend operation to start exchange process. Add server method to exchange authorization code for access (and refresh) token.
Input:

• authorization code
• server name

Output:

• access token
• refresh token (?)
• request info
• response info

Frontend should pass in an authorization code obtained on the previous step. The backend handler for the client request should

• get the server info by name
• build and call the token acquire uri

TOKEN_ENDPOINT?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

• wait until the API answer on the callback uri #8
• response with token or error message and api request/response

Token info has the format:

{
    "access_token":"ACCESS_TOKEN",
    "token_type":"bearer",
    "expires_in":2592000,
    "refresh_token":"REFRESH_TOKEN",
    "scope":"read"
}

with possible additional fields.

Привлекательные варианты:

• Ember 2.4
• Angular 2 beta
• ?

It is difficult to reason about the current flow mode without opening the settings dialog.

Probably they are not saved in the settings editor.

Should store server info:

• Name
• Authorization Endpoint
• Token Endpoint
• Client ID
• Client Secret

Ops! Completely forgot about it...

• Auth code request
• Implicit token request

Bearer, what else?