Skip to content

Conversation

bramcomyn
Copy link

@bramcomyn bramcomyn commented Aug 20, 2025

I introduced simple manual and automatic refreshing of the policies list in the ResourceExplorer component by adding a Button for manual refreshing and a timeout-interval for automatic refreshing every 10 seconds. This simply asks the podStore for the resources, just like it does when the component is loaded for the first time.

image

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).

@bramcomyn bramcomyn changed the title Refresh user policies in ResourceExplorer.vue Updates: cold start script and autorefresh Aug 20, 2025
@bramcomyn bramcomyn changed the title Updates: cold start script and autorefresh Documentation, cold start script, resource refreshing and controller ownership + global state Aug 20, 2025
@woutslabbinck woutslabbinck self-requested a review August 20, 2025 13:46
Copy link
Collaborator

@woutslabbinck woutslabbinck left a 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?

Copy link
Collaborator

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 -->

![use case visualization](./use_case.png)
Copy link
Collaborator

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.
Copy link
Collaborator

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", {
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants