When you create your page inheriting from OCSComponent you inherit all the methods including all managing your currentUser. Just override those. I would think that solves your problem without too much of legwork.
Have fun ---markus--- > On 9 Jan 2022, at 10:21, ocs--- via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > Hi there, > > I've got a pretty old application, the standard structure: there's Session > which (among others) contains a property currentUser containing the user who > has logged in and in whose account changes are performed. There is an > OCSComponent extends ERXComponent with generic component services (many of > which depend on session and/or its currentUser), and all my components > inherit this. > > Now I've got a new request to allow a given user to connect to _one specific > page_ in the application through a specific URL _without a login_ and do his > work in that page. > > I can easily generate appropriate URL for a direct action, which would set up > a session and open the desired page, that's easy. > > What I can't quite see is how to prevent the user to go elsewhere in the > application (e.g., by manually editing the URL) and stay logged in. Is there > some trick for that? > > So far I could think of two solutions: > > (i) add a property allowedPage to Session, and in my direct action set it up > appropriately. Then in the shared component awake at OCSComponent level I > could check whether this==allowedPage and log out the user if not. > > This looks like a good solution, but I am not entirely sure whether I am not > overlooking some tricky way the user still might stay logged in and get to > another page (without its awake performed)... is it completely safe? > > (ii) write a complete new page code (ERXComponent-based, skipping > OCSComponent altogether) for the specific page, which would contain and use > its own component-level currentUser. The direct action would set this up and > leave session.currentUser empty. > > This is self-evidently completely safe, but a _lot_ of legwork :/ > > Can you see another, better solution? Or can you see that (i) is indeed safe > enough? > > Thanks and all the best (especially happy and successful new year), > OC > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/dominik.huber%40rucotec.ch > > This email sent to dominik.hu...@rucotec.ch _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
