Markus,

thanks!

> On 9 Jan 2022, at 17:27, Markus Ruggiero <mailingli...@kataputt.com> wrote:
> 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.

Alas, the page (to which I need the special access) is not a new one to be 
created, but an existing non-trivial one; what's worse, it is not a direct 
subclass of OCSComponent, there's an intermediate class with another shared 
functionality. Aside of the inherited stuff, the page refers to the session 
both in its own code and also in the HTML template.

Thus, whilst this approach is technically possible, I am afraid it might prove 
more legwork than writing the component code afresh.

Unless.... hmmm, I wonder. Can I create an independent session for one specific 
page only this way?

===
class ThatDarnedComponent extends SomethingElse /* which extends OCSComponent 
which extends ERXComponent */ {
  Session specificPageOnlySessionAccess; // set up if no other page should 
share login
  Session session() {
    return specificPageOnlySessionAccess?:super.session()
  }
  ... ... all the rest unchanged
===
class DirectAction extends WODirectAction {
  WOActionResult thatDarnedAction() {
    def page=pageWithName("ThatDarnedComponent")
    page.specificPageOnlySessionAccess=new Session() // not shared, but 
specific for the page only; other pages would get different session
    page.specificPageOnlySessionAccess.currentUser=... user determined from 
request, details unimportant ...
    return page
  }
  ... ...
===

Might that work perhaps? Would any other component (if accessed anyhow) get a 
different session? Or would there be problems due to the specific session 
somehow shared, e.g., through a context or whatever?

Thanks and all the best,
OC

>> 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

Reply via email to