The UpdateManager.editable() function replies on looking at the cache of HTTP metadata in the store to see from the heads of an earlier GET or HEAD request whether the server has indicated that the client is allowed to write to the resource.
The problem is that if in the course of the flow of the app, a user is logged in, their ability to edit a resource may improve, bt the edit function doesn't know to refresh the editable() status.
One solution would be delete a bunch of metadata from the store on log in. Not ideal, as may losing useful information.
One could imagine for example having a proces-wide concept time of last login, and for the editable() function to ignore metadata before that time.
(Is there a level-braking problem between rdflib and solid,? Well, rdflib has to be aware of solid auth anyway....)
This all assumes that there is a process-wide concept of login, but in fact different resources on the web may in future be logged in to with different states and different webids even. So this sensitivity to login state would have to be domain my domain or pod by pod.
The UpdateManager.editable() function replies on looking at the cache of HTTP metadata in the store to see from the heads of an earlier GET or HEAD request whether the server has indicated that the client is allowed to write to the resource.
The problem is that if in the course of the flow of the app, a user is logged in, their ability to edit a resource may improve, bt the edit function doesn't know to refresh the editable() status.
One solution would be delete a bunch of metadata from the store on log in. Not ideal, as may losing useful information.
One could imagine for example having a proces-wide concept time of last login, and for the editable() function to ignore metadata before that time.
(Is there a level-braking problem between rdflib and solid,? Well, rdflib has to be aware of solid auth anyway....)
This all assumes that there is a process-wide concept of login, but in fact different resources on the web may in future be logged in to with different states and different webids even. So this sensitivity to login state would have to be domain my domain or pod by pod.
See eg meeting discussion