Consider porting the persistentId attributes to storage API
Description
Environment
Activity
Closing, there's not enough real value here to bother.
I did yet another cleanup of this code and promoted back another new API for this so I'm inclined to close but I guess for posterity I'll just unschedule it and leave it as a backlog.
I don't think there's any real reliability gain from changing to the other API. If there's a real solution, the new API can be used to implement a better plugin if somebody knows how to do that.
Not sure how sure we are that our current DB option is working, I don't know what the issues people are running into are. I kind of think Hibernate is messing up locks.
That's one concern I have doing this right now, it may shift the problem and we'll need to build a straight JDBC storage plugin.
Re: revocation, I really did wonder what people are doing now. If they routinely use the database table now to revoke stuff, then I guess that's a bigger issue than I was thinking. Clearly can be done of course, I'm just prioritizing.
I could live with a revocation tool (or even the design for one) that explicitly expects to find the database below our storgae layer if that was what it took to get it written. The wins of being able to use a working DB interface more than make up for that. And if someone is foolish enough to deploy this against something non databasey then thats their problem...
I do tend to do those cleanup checks inline, yeah, assuming I can't set actual expirations.
Wondered about the revocation thing, but noted we didn't have a way to do that now, technically.
With respect to compatibility, I think we'd have to do a tool. I think we would also have to keep the seed nonsense and all that, because we need this to be a drop-in replacement and the original was designed to let people migrate from hashed to stored IDs, etc.
That is admittedly where this whole race mess originates, the need to check for the count of IDs.
But I guess we could "inline" the tool if we really wanted to, and have it just convert on the fly. Need to think about it.
As discussed in the users list (http://shibboleth.net/pipermail/users/2015-September/024345.html) there are timing windows galore in the current implementation.
We could fix this, but a large part of the work would be duplicating stuff we have already had to do for the storage API.
Obviously deployers would be instructed to use DB implementations only (or at best warned against the side effects of using other implementations.