| 2016-01-07 13:03:21 |
John-Magne Bredal |
bug |
|
|
added bug |
| 2016-01-07 13:03:35 |
John-Magne Bredal |
tags |
|
navref |
|
| 2016-01-07 13:03:42 |
John-Magne Bredal |
nav: importance |
Undecided |
Wishlist |
|
| 2016-01-13 09:54:03 |
John-Magne Bredal |
description |
Provide token administration. Make it possible to connect tokens to users and
extend or revoke tokens. It must also be possible to set and modify how long
the token is valid.
Tokens must provide a more detailed authorization where having a token does
not automatically give you access to all of the API.
A token must be connected to a user. |
A summary of an initial discussion about this task follows:
Because the general authorization system is NAV is very basic and this
task is limited to the API, a token does not need to be connected to a
specific user. Knowing what user owns a token does not give any value
at the time of access. However, some way of connecting
meta-information to a token is necessary such as for instance comments
about what this token is for and who can be contacted regarding this
token.
The only way of providing more detailed authorization is by limiting
access by endpoints. There already exists a list of endpoints that is
displayed when visiting the API index, and this list may be used to
connect endpoints to tokens. If a token has access to an endpoint, no
further authorization is done (as in the web interface).
WEB INTERFACE
Token distribution is done by NAV admins. A web interface must be made
with the following specification:
- Located in "User administration" as a new tab "Token administration"
- Must list all active and revoked tokens with the following
information
- token, when created, when expires, comment, endpoints, status
(revoked, active, expired)
- Must have a way of creating a new token. Interface has
- token string created automatically
- sane default for expiry, but possible to set custom date
- dropdown list (multiple) to add endpoints (none default, option
for all)
- textfield to add comment
- status set to active
- Must have a way of editing the comment
- Must have a way of editing the endpoints available
- Must have a way of refreshing the expiry with a custom date
- Must have a way of setting status
- Must show when the token was last used to access the api
DATABASE CHANGES
The 'apitoken' table must be expanded with the following fields:
- created: timestamp not null
- comment: text
- status_id: integer not null references apitoken_status
- last_access: timestamp
A new table 'apitoken_status' must be made with the following fields
- id: serial primary key
- status: varchar(30) not null (populate with 'active', 'revoked',
'expired')
A new table 'apitoken_endpoints' that connects tokens and endpoints:
- token_id: integer not null references apitoken (id)
- endpoint_id: integer not null references api_endpoint (id)
A new table 'api_endpoint' listing all api endpoints available. This
should also be used to populate the api index
- id: serial primary key
- name: varchar(50) not null
- version: varchar(10)
- url: varchar(100) not null
Models for all tables must be created aswell. |
|
| 2016-01-13 13:42:54 |
John-Magne Bredal |
description |
A summary of an initial discussion about this task follows:
Because the general authorization system is NAV is very basic and this
task is limited to the API, a token does not need to be connected to a
specific user. Knowing what user owns a token does not give any value
at the time of access. However, some way of connecting
meta-information to a token is necessary such as for instance comments
about what this token is for and who can be contacted regarding this
token.
The only way of providing more detailed authorization is by limiting
access by endpoints. There already exists a list of endpoints that is
displayed when visiting the API index, and this list may be used to
connect endpoints to tokens. If a token has access to an endpoint, no
further authorization is done (as in the web interface).
WEB INTERFACE
Token distribution is done by NAV admins. A web interface must be made
with the following specification:
- Located in "User administration" as a new tab "Token administration"
- Must list all active and revoked tokens with the following
information
- token, when created, when expires, comment, endpoints, status
(revoked, active, expired)
- Must have a way of creating a new token. Interface has
- token string created automatically
- sane default for expiry, but possible to set custom date
- dropdown list (multiple) to add endpoints (none default, option
for all)
- textfield to add comment
- status set to active
- Must have a way of editing the comment
- Must have a way of editing the endpoints available
- Must have a way of refreshing the expiry with a custom date
- Must have a way of setting status
- Must show when the token was last used to access the api
DATABASE CHANGES
The 'apitoken' table must be expanded with the following fields:
- created: timestamp not null
- comment: text
- status_id: integer not null references apitoken_status
- last_access: timestamp
A new table 'apitoken_status' must be made with the following fields
- id: serial primary key
- status: varchar(30) not null (populate with 'active', 'revoked',
'expired')
A new table 'apitoken_endpoints' that connects tokens and endpoints:
- token_id: integer not null references apitoken (id)
- endpoint_id: integer not null references api_endpoint (id)
A new table 'api_endpoint' listing all api endpoints available. This
should also be used to populate the api index
- id: serial primary key
- name: varchar(50) not null
- version: varchar(10)
- url: varchar(100) not null
Models for all tables must be created aswell. |
A summary of an initial discussion about this task follows:
Because the general authorization system is NAV is very basic and this
task is limited to the API, a token does not need to be connected to a
specific user. Knowing what user owns a token does not give any value
at the time of access. However, some way of connecting
meta-information to a token is necessary such as for instance comments
about what this token is for and who can be contacted regarding this
token.
The only way of providing more detailed authorization is by limiting
access by endpoints. There already exists a list of endpoints that is
displayed when visiting the API index, and this list may be used to
connect endpoints to tokens. If a token has access to an endpoint, no
further authorization is done (as in the web interface).
WEB INTERFACE
Token distribution is done by NAV admins. A web interface must be made
with the following specification:
- Located in "User administration" as a new tab "Token administration"
- Must list all active and revoked tokens with the following
information
- token, when created, when expires, comment, endpoints, revoked
- Must have a way of creating a new token. Interface has
- token string created automatically
- sane default for expiry, but possible to set custom date
- dropdown list (multiple) to add endpoints (none default, option
for all)
- textfield to add comment
- status set to active
- Must have a way of editing the comment
- Must have a way of editing the endpoints available
- Must have a way of refreshing the expiry with a custom date
- Must have a way of revoking tokens
- Must show when the token was last used to access the api
DATABASE CHANGES
The 'apitoken' table must be expanded with the following fields:
- created: timestamp not null
- comment: text
- revoked: boolean default false
- last_access: timestamp
A new table 'apitoken_endpoints' that connects tokens and endpoints:
- token_id: integer not null references apitoken (id)
- endpoint_id: integer not null references api_endpoint (id)
A new table 'api_endpoint' listing all api endpoints available. This
should also be used to populate the api index
- id: serial primary key
- name: varchar(50) not null
- version: varchar(10)
- url: varchar(100) not null
Models for all tables must be created aswell. |
|
| 2016-01-13 13:46:02 |
John-Magne Bredal |
description |
A summary of an initial discussion about this task follows:
Because the general authorization system is NAV is very basic and this
task is limited to the API, a token does not need to be connected to a
specific user. Knowing what user owns a token does not give any value
at the time of access. However, some way of connecting
meta-information to a token is necessary such as for instance comments
about what this token is for and who can be contacted regarding this
token.
The only way of providing more detailed authorization is by limiting
access by endpoints. There already exists a list of endpoints that is
displayed when visiting the API index, and this list may be used to
connect endpoints to tokens. If a token has access to an endpoint, no
further authorization is done (as in the web interface).
WEB INTERFACE
Token distribution is done by NAV admins. A web interface must be made
with the following specification:
- Located in "User administration" as a new tab "Token administration"
- Must list all active and revoked tokens with the following
information
- token, when created, when expires, comment, endpoints, revoked
- Must have a way of creating a new token. Interface has
- token string created automatically
- sane default for expiry, but possible to set custom date
- dropdown list (multiple) to add endpoints (none default, option
for all)
- textfield to add comment
- status set to active
- Must have a way of editing the comment
- Must have a way of editing the endpoints available
- Must have a way of refreshing the expiry with a custom date
- Must have a way of revoking tokens
- Must show when the token was last used to access the api
DATABASE CHANGES
The 'apitoken' table must be expanded with the following fields:
- created: timestamp not null
- comment: text
- revoked: boolean default false
- last_access: timestamp
A new table 'apitoken_endpoints' that connects tokens and endpoints:
- token_id: integer not null references apitoken (id)
- endpoint_id: integer not null references api_endpoint (id)
A new table 'api_endpoint' listing all api endpoints available. This
should also be used to populate the api index
- id: serial primary key
- name: varchar(50) not null
- version: varchar(10)
- url: varchar(100) not null
Models for all tables must be created aswell. |
A summary of an initial discussion about this task follows:
Because the general authorization system is NAV is very basic and this
task is limited to the API, a token does not need to be connected to a
specific user. Knowing what user owns a token does not give any value
at the time of access. However, some way of connecting
meta-information to a token is necessary such as for instance comments
about what this token is for and who can be contacted regarding this
token.
The only way of providing more detailed authorization is by limiting
access by endpoints. There already exists a list of endpoints that is
displayed when visiting the API index, and this list may be used to
connect endpoints to tokens. If a token has access to an endpoint, no
further authorization is done (as in the web interface).
WEB INTERFACE
Token distribution is done by NAV admins. A web interface must be made
with the following specification:
- Located in "User administration" as a new tab "Token administration"
- Must list all active and revoked tokens with the following
information
- token, when created, when expires, comment, endpoints, revoked
- Must have a way of creating a new token. Interface has
- token string created automatically
- sane default for expiry, but possible to set custom date
- dropdown list (multiple) to add endpoints (none default, option
for all)
- textfield to add comment
- status set to active
- Must have a way of editing the comment
- Must have a way of editing the endpoints available
- Must have a way of refreshing the expiry with a custom date
- Must have a way of revoking tokens
- Must show when the token was last used to access the api
DATABASE CHANGES
The 'apitoken' table must be expanded with the following fields:
- created: timestamp not null
- comment: text
- revoked: boolean default false
- last_used: timestamp
A new table 'apitoken_endpoints' that connects tokens and endpoints:
- token_id: integer not null references apitoken (id)
- endpoint_id: integer not null references api_endpoint (id)
A new table 'api_endpoint' listing all api endpoints available. This
should also be used to populate the api index
- id: serial primary key
- name: varchar(50) not null
- version: varchar(10)
- url: varchar(100) not null
Models for all tables must be created aswell. |
|
| 2016-03-02 13:50:43 |
John-Magne Bredal |
nav: milestone |
|
4.5.0 |
|
| 2016-03-09 07:12:32 |
John-Magne Bredal |
nav: status |
New |
Fix Committed |
|
| 2016-03-09 07:21:30 |
John-Magne Bredal |
nav: assignee |
|
John-Magne Bredal (john-m-bredal) |
|
| 2016-06-09 10:51:02 |
Morten Brekkevold |
nav: status |
Fix Committed |
Fix Released |
|
