Aaron, thanks! Actually I could extend the user class easily, without a need to make a generic interface. Nevertheless I don't think either would help: in this particular case, the „canSeePage“ ability does not depend on the user, but only on whether the application has been connected to normally or through the specific DA. Thus it seems a bit more apt to store the ability to open the page session-level than user-level (although, of course, it would work too).
Thanks and all the best, OC > On 9 Jan 2022, at 17:28, Aaron Rosenzweig <aa...@chatnbike.com> wrote: > > OC, your idea will work, but here’s another to consider. > > Make an interface for user objects, call it “UserInterface” > > You are now free to have multiple types of user objects that all implement a > common interface. You can make your current User implement the interface and > now make a brand new User type for special access. > > In OCSComponent and your session, you work with objects of that interface. > > In OCSComponent make or modify “canSeePage()” method to know if a valid user > is authenticated and has ability to see the current page. Generally, it only > allows people of the old User type to access the page by default. > > In your new page, you can override “canSeePage()” to allow the new type of > User to have visibility. > >> On Jan 9, 2022, at 10:21 AM, 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/aaron%40chatnbike.com >> >> This email sent to aa...@chatnbike.com > _______________________________________________ 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
