[Seaside] A session-aware kind of FileLibrary - how/where to start
jtuchel at objektfabrik.de
jtuchel at objektfabrik.de
Tue Mar 30 12:56:27 UTC 2021
Hi Karsten,
thanks for your ideas. This needs a little bit of fiddling and tweaking,
but I think I found something that seems to work. I am not sure if this
is going to break something, but it does what I want...
I am not sure if this is a good approach, but maybe somebody wants to
comment on it:
* Create a Subclass of WARequestHandler
* Add an inst var @app and accessors to it
* In the method where the root component et al. are registered with
WAAdmin do:
*
attachmentsHandler := WAAdmin register: OfAttachmentsHandler at: 'att'.
attachmentsHandler app: app.
* In the handler's handleFiltered: method I do:
o
handleFiltered: aRequestContext
| fName user |
user := (self app sessions
detect: [:s | s key = (aRequestContext request queryFields at: '_s' ifAbsent: [nil])]
ifNone: [^nil])
user.
o ...
Does this look like a workable solution? If so, is there a nicer way of
searching for a session?
Bonus question:
... forget this one, Esteban just answered it in another answer and even
answered the question about the nicer way of searching for the session ;-)
Joachim
Am 30.03.21 um 12:34 schrieb Karsten Kusche:
> Hi Joachim,
>
> the session idea is handled and added by the applications. When a
> request is dispatched to the application, it „somehow“ reads the
> session information (typically via _s parameter). Then it can find out
> the session object using its cache object, where the _s parameter
> happens to be a key.
>
> If you want your file library to only respond to certain files in a
> certain session, you can transport the session-key in your url…maybe
> also as _s parameter. Then in your file-handler or in your file
> library you can take that parameter, ask the appropriate application
> (either always the same application or you pass the application name
> as another parameter) for the session and go from there.
>
> Another alternative is that you simply use your sessions continuation
> registry and register the file there. I think <img> and <a> tags can
> both be fed with Document objects that are responded when needed. That
> way your files would be accessible via /blah/_s=123&_k=34324, which
> your apache will pass through anyway.
>
> Kind Regards
> Karsten
>
> —
>
> Georg Heeg eK
> Wallstraße 22
> 06366 Köthen
>
> Tel.: 03496/214328
> FAX: 03496/214712
> Amtsgericht Dortmund HRA 12812
>
>
> Am 30. März 2021 um 12:11:22, jtuchel at objektfabrik.de
> (jtuchel at objektfabrik.de <mailto:jtuchel at objektfabrik.de>) schrieb:
>
>> Hi Sven,
>>
>> I started with a WAFileLibrary subclass first. I couldn't get it to
>> work the way I wanted.
>>
>> One of the problems is that all FileLibraries added by addLibrary:
>> end up as an endpoint in the /files path, unless I also register a
>> WAFileHandler (subclass) at another endpoint. In my case, I'd like to
>> separate things: /files is for "public" files, and then there should
>> be /attachments for "private" stuff of my users. AFAIK there is no
>> way to register an additional File Library in another path/endpoint
>> then /files, or is there? (this really is a question, not an
>> argument...). Why do I want that? Because I want to keep the
>> configuration of the frontend web server (Apache in my case) simple.
>> Redirecting all requests of /files and subdirectories to some folder
>> is easy. Not sure whether redirecting all but one is just as easy...?
>>
>> The other one is that a WAFileLibrary subclass doesn't know its
>> session either. As an experimented I added this override to one of my
>> FileLibraries:
>> handle: aRequestContext
>> self session ifNotNil: [:s| s halt].
>> super handle: aRequestContext
>>
>> And it never halts. This makes some sense, because in order to save
>> files, you don't need a session. Anybody can have these files. And
>> that is what I don't want for some files...
>>
>> So I started subclassing WAFileHandler and found out a FileHandler
>> doesn't know the session either . But I want to have access to the
>> logged-ob user in the session. So it seems I either have to subclass
>> from something else or add "something" to my WAFileHandler in the
>> Application configuration, like a Filter or whetever...
>>
>> So either I need to know something more about FileLibraries (register
>> at something else than /files, make them session aware) or
>> FileLibrary is not what I have to subclass...
>>
>> Any more ideas?
>>
>> Joachim
>>
>>
>>
>>
>>
>>
>> Am 30.03.21 um 11:51 schrieb Sven Van Caekenberghe:
>>> Hi Joachim,
>>>
>>> I would try to look at WAFileHandler, which is responsible for serving the files.
>>>
>>> It seems to delegate most work to WAFileLibrary>>#handle:
>>>
>>> Maybe you can subclass WAFileLibrary (insert your superclass before your concrete class) to check the session for a login.
>>>
>>> Sven
>>>
>>>> On 30 Mar 2021, at 11:18,jtuchel at objektfabrik.de wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>> There are situations in which I feel like after 10+ years of using Seaside, I am still a newbie. (well, same for Smalltalk after 25+ years, so this may be normal).
>>>>
>>>> I would like to implement some kind of FileLibrary that is aware of the current session and only delivers files to logged-on users.
>>>>
>>>> It seems like the best starting point for this is to subclass WARequestHandler and register it with WAAdmin. So the first thing I did was implement handleFiltered: aRequestContext. Unfortunately, neither aRequestContext nor self return a WASession, although I entered _s and _k form a logged in session into the address bar of my Browser. This may be a naive approach, but as a fist test case this seemed like a good idea ;-)
>>>>
>>>> Now the question I ask myself is: how do I teach my WARequestHandler subclass the trick of knowing/finding the current session. Do I add some Filter? Is subclassing WARequestHandler the wrong idea anyways? (I started my experiments with a subclass of WAFileLibrary, but that also didn't get me anywhere...).
>>>>
>>>> I am not asking for a ready-made solution. I'd rather try to understand a little more about Seasides innards here...
>>>>
>>>> Any pointers? Kick-off ideas what to look at?
>>>>
>>>>
>>>> tia,
>>>>
>>>>
>>>> Joachim
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------------------------
>>>> Objektfabrik Joachim Tuchelmailto:jtuchel at objektfabrik.de
>>>> Fliederweg 1http://www.objektfabrik.de
>>>> D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>>>>
>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>> seaside at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>> --
>> -----------------------------------------------------------------------
>> Objektfabrik Joachim Tuchelmailto:jtuchel at objektfabrik.de
>> Fliederweg 1http://www.objektfabrik.de
>> D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuchel at objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20210330/4cbf901e/attachment-0001.html>
More information about the seaside
mailing list