-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add authorization scope mechanism #288
Labels
Comments
This was referenced May 3, 2023
Closed
This was referenced May 31, 2023
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 6, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 7, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 7, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 7, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field
Leobouloc
added a commit
that referenced
this issue
Jun 7, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jun 13, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jun 13, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jun 13, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jun 13, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jun 13, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jun 13, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
…g authority In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
…g authority In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
wilbrdt
pushed a commit
that referenced
this issue
Jul 12, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
quitterie-lcs
pushed a commit
that referenced
this issue
Jul 21, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
quitterie-lcs
pushed a commit
that referenced
this issue
Jul 21, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
quitterie-lcs
pushed a commit
that referenced
this issue
Jul 21, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
quitterie-lcs
pushed a commit
that referenced
this issue
Jul 21, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jul 25, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
Leobouloc
added a commit
that referenced
this issue
Jul 25, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Leobouloc
added a commit
that referenced
this issue
Jul 25, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
Leobouloc
added a commit
that referenced
this issue
Jul 25, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
wilbrdt
pushed a commit
that referenced
this issue
Jul 31, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
wilbrdt
pushed a commit
that referenced
this issue
Jul 31, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
wilbrdt
pushed a commit
that referenced
this issue
Aug 2, 2023
In link with #288 , we need a mechanism to assign an "Agent" (in the sense of the xAPI specification) to a user (to later be able to infer the "Authority" field when writing a statement). It was proposed to add the "agent" representation as a field in the user credentials, which is what is implemented here. There is no contraint as to which of the 4 valid IFI's must be used. BREAKING: New users must now include an agent field It affects both Basic HTTP and OpenIdConnect authentication methods.
wilbrdt
pushed a commit
that referenced
this issue
Aug 2, 2023
In link with #288 , we need a mechanism to fetch statements by authority. It has been decided that the GET /statements endpoint will implement a mine option (not in xAPI specification), which is used to return only the statements for which the "authority" field matches the "agent" field of the current user (stored in credentials since #342, or given through token claims). With future implementation of permissions, it is expected that the use of mine option will be made mandatory for users of the API that do not have full read access. The idea behind this is to make any filtering obvious to the user ("explicit is better than implicit"). This commit adds mine by fetching user "agent" field and querying using a new database query field.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Request
Is your feature request related to a problem or unsupported use case? Please describe.
With the addition of the OpenId Connect authentication into Ralph, we should, as mentionned by the xAPI spec, implement scopes.
Describe the solution you'd like
In a first implementation, we could implement the following scopes:
all/read
all
statements/write
statements/read
statements/read/mine
Discovery, Documentation, Adoption, Migration Strategy
We will probably have to add an Authority mechanism, necessary for the
statements/read/mine
scope.The text was updated successfully, but these errors were encountered: