Ben Alex wrote:
I would probably try to avoid doing the run-as replacement, as it is a little challenging to overcome the issue you've described without creating the user an entirely different way or exposing an internal token used by AbstractSecurityInterceptor (which I would rather not do, as it could pose a lot of problematic behavior if misunderstood/misused).
right, that's exactly what i thought.
Have you considered using a different FilterChainProxy for the sign-up URL? That different chain could use a different AnonymousProcessingFilter bean that grants the necessary root role that the JCR requires. This would avoid the need to perform run-as replacement and overcome the central problem of modifying the SecurityContextHolder so that it is stored in the HttpSession at the end of the request.
hm, no, i hadn't thought of doing that. i'll see if that works, thanks.
Incidentally, I thought you were doing WebDAV stuff with JCR. If so, WebDAV clients are meant to use digest authentication which is nice and convenient as there's no HttpSession required.
i am, but this is for the web user interface that lets people sign up for accounts on the server and so forth.
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
