-
Notifications
You must be signed in to change notification settings - Fork 3
Documentation, cold start script, resource refreshing and controller ownership + global state #45
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
base: feat/odrl
Are you sure you want to change the base?
Conversation
…ea in documentation
ResourceExplorer.vue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work so far.
I have some small remarks and suggestions (some of which we already discussed offline).
Could you incorporate the requested changes?
documentation/as-assignment.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be updated when we can update the authorization server in LOAMA, right?
Especially since we have thee global controller now
|
||
<!-- TODO: this visualization is not completely correct and should be updated --> | ||
|
||
 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make it a bit more clear what we are focusing on and what is UMA?
The RO is definetly involved in this use case, more specific, both RP and RO will use LOAMA to perform the negotiation of a permission.
The RP will use a different client to (UMA client perhaps) to get actual access to the resource.
The UMA AS implementation should provide this coupling internally in order to provide ROs with requests concering their resources. | ||
|
||
- **absence of policies for resources**: the current UMA AS implementation holds a record of policies for resources. | ||
When the AS receives a request for access to an unknown resource, it should possibly not return a 404 status code, as to not leak the information about the non-existence of a certain resource. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should possibly not return a 404 status code
this is confusing.
What are we saying here exactly?
Our current implementation basically allows to access for "all" resources, even if those resources do not exist yet. Right?
So indeed, if there is no current policy over a resource, the access request should still be sent tot the AS
// ATM it only holds one: specifically for ODRL. | ||
|
||
// perhaps it would be wiser to make some enumeration of all supported AS types | ||
export const useControllerStore = defineStore("controller", { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if this store is to be used for other global variables, should the name not better be a generic one?
E.g. useStore
…e selected controller in the store
I introduced simple manual and automatic refreshing of the policies list in the
ResourceExplorer
component by adding aButton
for manual refreshing and a timeout-interval for automatic refreshing every 10 seconds. This simply asks thepodStore
for the resources, just like it does when the component is loaded for the first time.I also added a cold start script to easily add new policies for users. This script can be run by using
npm run cold
and entering the required information. I also added documentation on this cold start problem and added documentation on how I'd propose dynamically configuring the Authorization Server (AS).