A session-aware kind of FileLibrary - how/where to start

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

A session-aware kind of FileLibrary - how/where to start

jtuchel
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 Tuchel          mailto:[hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

Sven Van Caekenberghe-2
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, [hidden email] 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 Tuchel          mailto:[hidden email]
> 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
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

jtuchel
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, [hidden email] 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 Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

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, [hidden email] ([hidden email]) 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, [hidden email] 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 Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


--  
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

JupiterJones
In reply to this post by jtuchel
This may be a little left-field, but if you want a more integrated approach you could try something like:


renderContentOn: canvas
        canvas anchor
                url: (self fileAccessUtlFroFile: #restrictedAccessFile);
                with: ‘Download'


fileAccessUrlForFile: fileIdentifier
        ^self renderContext actionUrl copy
                addField:
                        (self renderContext callbacks
                                store: (WAActionCallback on: [ self processFileAccessCallbackForFile: fileIdentifier ]));
                yourself.


processFileAccessCallbackForFile: fileIdentifier
        (self session isUserAllowedToDownloadFile: fileIndeitifier) ifTrue: [
                self requestContext response redirectTo: (self actualUrlForFile: fileIdentifier)
        ]


You could also serve the file directly in the response rather than #redirectTo: if you wanted added security.

The above is incomplete, but perhaps fits the brief.

Cheers,

Jupiter

> On 30 Mar 2021, at 8:18 pm, [hidden email] 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 Tuchel          mailto:[hidden email]
> 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
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

Esteban A. Maringolo
In reply to this post by Sven Van Caekenberghe-2
On Tue, Mar 30, 2021 at 6:51 AM Sven Van Caekenberghe <[hidden email]> wrote:
> I would try to look at WAFileHandler, which is responsible for serving the files.

I thought about the same approach.

1. Implement some WARestrictedFileHandler subclass of WAFileHandler,
where you configure (via a preference or plain instVar) the identifier
of the app that has the session registry (e.g. 'myApp')
2. In the handleFiltered: you get a reference to that WAApplication
and then you do something like:

handleFiltered: aRequestContext
  | app key session |
  app := WAAdmin defaultDispatcher handlerAt: 'myApp'.
  key := app trackingStrategy keyFromContext: aRequestContext.
  key isNil
    ifTrue: [ "generate the 403 response" ]
    ifFalse: [
     session := app cache at: key ifAbsent: [ nil ].
     session isNil
       ifTrue: [ "generate 403" ]
       ifFalse: [ ("check whether session is valid" ) ifTrue: [^super
handleFiltered: aRequestContext] ifFalse: ["403..."]
    ]
]

So the approach is to externally access the app session registry and
fetch the session from there.

What is not clear to me is whether you want to restrict access to
regular Seaside FileLibraries or to some other mapping to static files
in a filesystem.

Regards,

Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

jtuchel
In reply to this post by Karsten Kusche
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:
    • handleFiltered: aRequestContext
          | fName user |
          user := (self app sessions
              detect: [:s | s key = (aRequestContext request queryFields at: '_s' ifAbsent: [nil])]
              ifNone: [^nil])
                  user.
    • ...

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, [hidden email] ([hidden email]) 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, [hidden email] 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 Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


--  
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

jtuchel
In reply to this post by JupiterJones
Jupiter,


sorry for my late reply. For some reason, your answer was moved to my
spam folder and I just found it there between lots of pharma and crypto
tips...

While I see where you are headed with this, I wonder if there are
differences between the approaches. I have the feeling a separate
WAFileHandler might have the advantage of being more decoupled from the
components that consume/refer/use files. And I wonder if a separate
WAFileHandler might decouple things a little more, like allowing for
parallel execution of requests?

Joachim








Am 30.03.21 um 14:23 schrieb Jupiter Jones:

> This may be a little left-field, but if you want a more integrated approach you could try something like:
>
>
> renderContentOn: canvas
> canvas anchor
> url: (self fileAccessUtlFroFile: #restrictedAccessFile);
> with: ‘Download'
>
>
> fileAccessUrlForFile: fileIdentifier
> ^self renderContext actionUrl copy
> addField:
> (self renderContext callbacks
> store: (WAActionCallback on: [ self processFileAccessCallbackForFile: fileIdentifier ]));
> yourself.
>
>
> processFileAccessCallbackForFile: fileIdentifier
> (self session isUserAllowedToDownloadFile: fileIndeitifier) ifTrue: [
> self requestContext response redirectTo: (self actualUrlForFile: fileIdentifier)
> ]
>
>
> You could also serve the file directly in the response rather than #redirectTo: if you wanted added security.
>
> The above is incomplete, but perhaps fits the brief.
>
> Cheers,
>
> Jupiter
>
>> On 30 Mar 2021, at 8:18 pm, [hidden email] 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 Tuchel          mailto:[hidden email]
>> 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
>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

Karsten Kusche
Hi Joachim,

I think serving files via FileHandler or via callback-registry is pretty much the same performance wise. If you use the callback-registry then the mechanisms that lead to the callback-registry already take care of the session-specific stuff. Having a file handler at /files typically allows for using an apache for serving files. In that case however you cannot use the session-key, so your new file-handler will not help much performance wise.

Kind Regards
Karsten

— 

Georg Heeg eK
Wallstraße 22
06366 Köthen

Tel.: 03496/214328
FAX: 03496/214712
Amtsgericht Dortmund HRA 12812


Am 1. April 2021 um 06:59:35, [hidden email] ([hidden email]) schrieb:

Jupiter,


sorry for my late reply. For some reason, your answer was moved to my
spam folder and I just found it there between lots of pharma and crypto
tips...

While I see where you are headed with this, I wonder if there are
differences between the approaches. I have the feeling a separate
WAFileHandler might have the advantage of being more decoupled from the
components that consume/refer/use files. And I wonder if a separate
WAFileHandler might decouple things a little more, like allowing for
parallel execution of requests?

Joachim








Am 30.03.21 um 14:23 schrieb Jupiter Jones:
> This may be a little left-field, but if you want a more integrated approach you could try something like:
>
>
> renderContentOn: canvas
> canvas anchor
> url: (self fileAccessUtlFroFile: #restrictedAccessFile);
> with: ‘Download'
>
>
> fileAccessUrlForFile: fileIdentifier
> ^self renderContext actionUrl copy
> addField:
> (self renderContext callbacks
> store: (WAActionCallback on: [ self processFileAccessCallbackForFile: fileIdentifier ]));
> yourself.
>
>
> processFileAccessCallbackForFile: fileIdentifier
> (self session isUserAllowedToDownloadFile: fileIndeitifier) ifTrue: [
> self requestContext response redirectTo: (self actualUrlForFile: fileIdentifier)
> ]
>
>
> You could also serve the file directly in the response rather than #redirectTo: if you wanted added security.
>
> The above is incomplete, but perhaps fits the brief.
>
> Cheers,
>
> Jupiter
>
>> On 30 Mar 2021, at 8:18 pm, [hidden email] 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 Tuchel mailto:[hidden email]
>> 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
>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:[hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

JupiterJones
In reply to this post by jtuchel
Hi Joachim,

Not sure why email clients think my messages are spam… I’m starting to think it’s personal :) That said, today I’m getting bounces back from the seaside mailing list so I’m copying this to you directly since this may nott make it to the list.

And I wonder if a separate WAFileHandler might decouple things a little more, like allowing for parallel execution of requests?

Yes and no :) If you’re deploying in GemStone and running multiple gems, you’ll get “effective" parallel execution for free and each gem will be able to lookup the _s key. If you’re deploying in Pharo, then you’ll need to save the _s keys (and any other information needed for validation) in a DB so that each Pharo instance can find them. This adds a layer of complexity and will likely negate any speed advantage gained through parallel execution.

All the solutions offered can work well. It really depends on the use case, production environment and scaling requirements. As Karsten mentioned,  typically in production you don’t want to serve files from the image - this doesn’t scale well, and becomes more problematic the larger the files. Rather you have nginx (or whatever http server you use) serve the files directly.

In that case, the FileLibrary is only providing urls, not serving content, so best to check user access before rendering the initial URL. This still doesn’t help if access security is the goal, since once the user has the URL, they can distribute it or use it anytime they like.

Another alternative that solves some of these issues, is having nginx validate file permissions via seaside when a file is accessed. This scales better since the image is only required to validate requests, and the http server delivers the file.

This also works if you want to validate files that aren’t in FileLibraries since it’s based on a url path, or if you want to allow WebDAV access so your users can mount a server directory on their desktop but still have fine-grain access control validated via seaside.

A example of how to perform a simple validation for a specific FileLibrary is something like:

nginx.conf:

upstream seaside_http {
server localhost:8383;
}

location ~ /files/MyFileLibrary {
auth_request /seasideAuth;
}

location = /seasideAuth {
proxy_pass  http://seaside_http/seasideAuth;
proxy_pass_request_body  off;
proxy_set_header  Content-Length  "";
proxy_set_header  X-Original-URI  $request_uri;
}

Then create a handler and register in seaside as ’seasideAuth'

WARequestHandler subclass: ‘NginxAuthRequestHandler’.
WAAdmin register: NginxAuthRequestHandler as: ’seasideAuth’.

The methods in NginxAuthRequestHandler would be something like:

handleFiltered: aRequestContext
[  self handleAuthorisation: aRequestContext ]
on: Error
do: [ :ex | aRequestContext responseGenerator forbidden ]

handleAuthorisation: aRequestContext 
self canAccessUri: (aRequestContext request headers at: ‘original-uri’).
ifTrue: [ aRequestContext responseGenerator respond ]
ifFalse: [ aRequestContext responseGenerator forbidden ]

canAccessUri: aUri
“do whatever needed to confirm access”
^ true

Again, this is incomplete, but you’ll get the idea. If you’re looking up sessions you’ll still need to add the _s key to the download url.

Cheers,

J

On 1 Apr 2021, at 3:59 pm, [hidden email] wrote:

Jupiter,


sorry for my late reply. For some reason, your answer was moved to my spam folder and I just found it there between lots of pharma and crypto tips...

While I see where you are headed with this, I wonder if there are differences between the approaches. I have the feeling a separate WAFileHandler might have the advantage of being more decoupled from the components that consume/refer/use files. And I wonder if a separate WAFileHandler might decouple things a little more, like allowing for parallel execution of requests?

Joachim








Am 30.03.21 um 14:23 schrieb Jupiter Jones:
This may be a little left-field, but if you want a more integrated approach you could try something like:


renderContentOn: canvas
canvas anchor
url: (self fileAccessUtlFroFile: #restrictedAccessFile);
with: ‘Download'


fileAccessUrlForFile: fileIdentifier
^self renderContext actionUrl copy
addField:
(self renderContext callbacks
store: (WAActionCallback on: [ self processFileAccessCallbackForFile: fileIdentifier ]));
yourself.


processFileAccessCallbackForFile: fileIdentifier
(self session isUserAllowedToDownloadFile: fileIndeitifier) ifTrue: [
self requestContext response redirectTo: (self actualUrlForFile: fileIdentifier)
]


You could also serve the file directly in the response rather than #redirectTo: if you wanted added security.

The above is incomplete, but perhaps fits the brief.

Cheers,

Jupiter

On 30 Mar 2021, at 8:18 pm, [hidden email] 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 Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

jtuchel
In reply to this post by Esteban A. Maringolo
Esteban,


I used your suggestion and it works very nicely. In development ;-)

Here are 2 things I encountered in a deployed image

  1. If the _s parameter is not the first one in the URL, the tracking Strategy will always return a nil key. Not sure why, especially in the light of the fact that this works fine in a dev image
  2. I have troubles getting things to work behind a load-balancing Apache because of the path. This one is really critical to me, let me explain:

I have configured Apache with mod_proxy_balancer to distribute load in sticky sessions to a few images who all listen to localhost:xxxx/MyApp. Since my Pseudo-FileLibrary needs the session context, it is necessary that all traffic of a session goes to the same image. So far, so well-known and logical.

The trouble is: my Application ist registered at: /MyApp, while the Pseudo-FileLibrary is registered at: /documents

This means that Apache mod_proxy_balancer will redirect all requests that get sent to https://mydomain/documents to https://mydomain/MyApp, which means a link or img tag points to the login page instead of a document served by my Pseudo File Library. The Pseudo File Library never gets to see a request...

I couldn't find a way to register a WARequestHandler subclass as a sub-path of a registered App. Because what I need is to register my Handler at /MyApp/documents.

WAAdmin register: MyHandler at: 'MyApp/documents'

throws an error: MyHandler doesNotUnderstand: key:.


So: how can I register a WARequestHandler at a subpath like /MyApp/documents?
Or, alternatively: how can I redirect incoming requests for /MyApp/documents to /documents within my image? (It seems hard to impossible to configure this on the Apache side...)


Any ideas or hints?



Joachim





Am 30.03.21 um 14:54 schrieb Esteban Maringolo:
On Tue, Mar 30, 2021 at 6:51 AM Sven Van Caekenberghe [hidden email] wrote:
I would try to look at WAFileHandler, which is responsible for serving the files.
I thought about the same approach.

1. Implement some WARestrictedFileHandler subclass of WAFileHandler,
where you configure (via a preference or plain instVar) the identifier
of the app that has the session registry (e.g. 'myApp')
2. In the handleFiltered: you get a reference to that WAApplication
and then you do something like:

handleFiltered: aRequestContext
  | app key session |
  app := WAAdmin defaultDispatcher handlerAt: 'myApp'.
  key := app trackingStrategy keyFromContext: aRequestContext.
  key isNil
    ifTrue: [ "generate the 403 response" ]
    ifFalse: [
     session := app cache at: key ifAbsent: [ nil ].
     session isNil
       ifTrue: [ "generate 403" ]
       ifFalse: [ ("check whether session is valid" ) ifTrue: [^super
handleFiltered: aRequestContext] ifFalse: ["403..."]
    ]
]

So the approach is to externally access the app session registry and
fetch the session from there.

What is not clear to me is whether you want to restrict access to
regular Seaside FileLibraries or to some other mapping to static files
in a filesystem.

Regards,

Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

jtuchel

I solved the problem differently, because this was going to be complicated...

I just found that WADocumentHandler is quite exactly what I was looking for. It even has a few advantages for my use case: it doesn't even need to transport any information about the file to the Browser, it just renders a  _d parameter and is only valid within the session. A pity that I overlooked this at my first attempt to solve the problem. It took me a few hours to rewrite things and now I have what I wanted: I can serve files which have no guessable URLs and can only be served within a session.

It also solves the Apache Load Balancer problem, because the IMG or A paramters are URLs within /MyApp, just like any other component. So no need to register it in any location that can be handled correctly by mod_proxy_balancer and stuff.


Thanks for listening and have a nice rest-of-the-weekend!


Joachim





Am 11.04.21 um 07:45 schrieb [hidden email]:
Esteban,


I used your suggestion and it works very nicely. In development ;-)

Here are 2 things I encountered in a deployed image

  1. If the _s parameter is not the first one in the URL, the tracking Strategy will always return a nil key. Not sure why, especially in the light of the fact that this works fine in a dev image
  2. I have troubles getting things to work behind a load-balancing Apache because of the path. This one is really critical to me, let me explain:

I have configured Apache with mod_proxy_balancer to distribute load in sticky sessions to a few images who all listen to localhost:xxxx/MyApp. Since my Pseudo-FileLibrary needs the session context, it is necessary that all traffic of a session goes to the same image. So far, so well-known and logical.

The trouble is: my Application ist registered at: /MyApp, while the Pseudo-FileLibrary is registered at: /documents

This means that Apache mod_proxy_balancer will redirect all requests that get sent to https://mydomain/documents to https://mydomain/MyApp, which means a link or img tag points to the login page instead of a document served by my Pseudo File Library. The Pseudo File Library never gets to see a request...

I couldn't find a way to register a WARequestHandler subclass as a sub-path of a registered App. Because what I need is to register my Handler at /MyApp/documents.

WAAdmin register: MyHandler at: 'MyApp/documents'

throws an error: MyHandler doesNotUnderstand: key:.


So: how can I register a WARequestHandler at a subpath like /MyApp/documents?
Or, alternatively: how can I redirect incoming requests for /MyApp/documents to /documents within my image? (It seems hard to impossible to configure this on the Apache side...)


Any ideas or hints?



Joachim





Am 30.03.21 um 14:54 schrieb Esteban Maringolo:
On Tue, Mar 30, 2021 at 6:51 AM Sven Van Caekenberghe [hidden email] wrote:
I would try to look at WAFileHandler, which is responsible for serving the files.
I thought about the same approach.

1. Implement some WARestrictedFileHandler subclass of WAFileHandler,
where you configure (via a preference or plain instVar) the identifier
of the app that has the session registry (e.g. 'myApp')
2. In the handleFiltered: you get a reference to that WAApplication
and then you do something like:

handleFiltered: aRequestContext
  | app key session |
  app := WAAdmin defaultDispatcher handlerAt: 'myApp'.
  key := app trackingStrategy keyFromContext: aRequestContext.
  key isNil
    ifTrue: [ "generate the 403 response" ]
    ifFalse: [
     session := app cache at: key ifAbsent: [ nil ].
     session isNil
       ifTrue: [ "generate 403" ]
       ifFalse: [ ("check whether session is valid" ) ifTrue: [^super
handleFiltered: aRequestContext] ifFalse: ["403..."]
    ]
]

So the approach is to externally access the app session registry and
fetch the session from there.

What is not clear to me is whether you want to restrict access to
regular Seaside FileLibraries or to some other mapping to static files
in a filesystem.

Regards,

Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

Annick
Hi Joachim,


You can register your files in a composite url by using 2 steps  (for instance clubs/fichiers)

(Seaside.WAAdmin defaultDispatcher handlers at: 'clubs')
        register: Seaside.WAFileHandler default
        at: 'fichiers’.

Annick

Le 11 avr. 2021 à 14:11, [hidden email] a écrit :

I solved the problem differently, because this was going to be complicated...

I just found that WADocumentHandler is quite exactly what I was looking for. It even has a few advantages for my use case: it doesn't even need to transport any information about the file to the Browser, it just renders a  _d parameter and is only valid within the session. A pity that I overlooked this at my first attempt to solve the problem. It took me a few hours to rewrite things and now I have what I wanted: I can serve files which have no guessable URLs and can only be served within a session.

It also solves the Apache Load Balancer problem, because the IMG or A paramters are URLs within /MyApp, just like any other component. So no need to register it in any location that can be handled correctly by mod_proxy_balancer and stuff.


Thanks for listening and have a nice rest-of-the-weekend!


Joachim





Am 11.04.21 um 07:45 schrieb [hidden email]:
Esteban,


I used your suggestion and it works very nicely. In development ;-)

Here are 2 things I encountered in a deployed image

  1. If the _s parameter is not the first one in the URL, the tracking Strategy will always return a nil key. Not sure why, especially in the light of the fact that this works fine in a dev image
  2. I have troubles getting things to work behind a load-balancing Apache because of the path. This one is really critical to me, let me explain:

I have configured Apache with mod_proxy_balancer to distribute load in sticky sessions to a few images who all listen to localhost:xxxx/MyApp. Since my Pseudo-FileLibrary needs the session context, it is necessary that all traffic of a session goes to the same image. So far, so well-known and logical.

The trouble is: my Application ist registered at: /MyApp, while the Pseudo-FileLibrary is registered at: /documents

This means that Apache mod_proxy_balancer will redirect all requests that get sent to https://mydomain/documents to https://mydomain/MyApp, which means a link or img tag points to the login page instead of a document served by my Pseudo File Library. The Pseudo File Library never gets to see a request...

I couldn't find a way to register a WARequestHandler subclass as a sub-path of a registered App. Because what I need is to register my Handler at /MyApp/documents.

WAAdmin register: MyHandler at: 'MyApp/documents'

throws an error: MyHandler doesNotUnderstand: key:.


So: how can I register a WARequestHandler at a subpath like /MyApp/documents?
Or, alternatively: how can I redirect incoming requests for /MyApp/documents to /documents within my image? (It seems hard to impossible to configure this on the Apache side...)


Any ideas or hints?



Joachim





Am 30.03.21 um 14:54 schrieb Esteban Maringolo:
On Tue, Mar 30, 2021 at 6:51 AM Sven Van Caekenberghe [hidden email] wrote:
I would try to look at WAFileHandler, which is responsible for serving the files.
I thought about the same approach.

1. Implement some WARestrictedFileHandler subclass of WAFileHandler,
where you configure (via a preference or plain instVar) the identifier
of the app that has the session registry (e.g. 'myApp')
2. In the handleFiltered: you get a reference to that WAApplication
and then you do something like:

handleFiltered: aRequestContext
  | app key session |
  app := WAAdmin defaultDispatcher handlerAt: 'myApp'.
  key := app trackingStrategy keyFromContext: aRequestContext.
  key isNil
    ifTrue: [ "generate the 403 response" ]
    ifFalse: [
     session := app cache at: key ifAbsent: [ nil ].
     session isNil
       ifTrue: [ "generate 403" ]
       ifFalse: [ ("check whether session is valid" ) ifTrue: [^super
handleFiltered: aRequestContext] ifFalse: ["403..."]
    ]
]

So the approach is to externally access the app session registry and
fetch the session from there.

What is not clear to me is whether you want to restrict access to
regular Seaside FileLibraries or to some other mapping to static files
in a filesystem.

Regards,

Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

jtuchel
Hi Annick,


thanks a lot for this information. Would've saved my sunday ;-)
I tried a few "something"s in that direction but failed, so I ended up rewriting the whole thing to using WADocumentHandler. I am happy with the results for now, but there is a feeling of "maybe it is not going to be flexible enough in the future". So it is good to know this. I liked the way a WAFileHandler worked in my dev image.

I wonder where/how you found this info?


Joachim






Am 12.04.21 um 09:51 schrieb List:
Hi Joachim,


You can register your files in a composite url by using 2 steps  (for instance clubs/fichiers)

(Seaside.WAAdmin defaultDispatcher handlers at: 'clubs')
        register: Seaside.WAFileHandler default
        at: 'fichiers’.

Annick

Le 11 avr. 2021 à 14:11, [hidden email] a écrit :

I solved the problem differently, because this was going to be complicated...

I just found that WADocumentHandler is quite exactly what I was looking for. It even has a few advantages for my use case: it doesn't even need to transport any information about the file to the Browser, it just renders a  _d parameter and is only valid within the session. A pity that I overlooked this at my first attempt to solve the problem. It took me a few hours to rewrite things and now I have what I wanted: I can serve files which have no guessable URLs and can only be served within a session.

It also solves the Apache Load Balancer problem, because the IMG or A paramters are URLs within /MyApp, just like any other component. So no need to register it in any location that can be handled correctly by mod_proxy_balancer and stuff.


Thanks for listening and have a nice rest-of-the-weekend!


Joachim





Am 11.04.21 um 07:45 schrieb [hidden email]:
Esteban,


I used your suggestion and it works very nicely. In development ;-)

Here are 2 things I encountered in a deployed image

  1. If the _s parameter is not the first one in the URL, the tracking Strategy will always return a nil key. Not sure why, especially in the light of the fact that this works fine in a dev image
  2. I have troubles getting things to work behind a load-balancing Apache because of the path. This one is really critical to me, let me explain:

I have configured Apache with mod_proxy_balancer to distribute load in sticky sessions to a few images who all listen to localhost:xxxx/MyApp. Since my Pseudo-FileLibrary needs the session context, it is necessary that all traffic of a session goes to the same image. So far, so well-known and logical.

The trouble is: my Application ist registered at: /MyApp, while the Pseudo-FileLibrary is registered at: /documents

This means that Apache mod_proxy_balancer will redirect all requests that get sent to https://mydomain/documents to https://mydomain/MyApp, which means a link or img tag points to the login page instead of a document served by my Pseudo File Library. The Pseudo File Library never gets to see a request...

I couldn't find a way to register a WARequestHandler subclass as a sub-path of a registered App. Because what I need is to register my Handler at /MyApp/documents.

WAAdmin register: MyHandler at: 'MyApp/documents'

throws an error: MyHandler doesNotUnderstand: key:.


So: how can I register a WARequestHandler at a subpath like /MyApp/documents?
Or, alternatively: how can I redirect incoming requests for /MyApp/documents to /documents within my image? (It seems hard to impossible to configure this on the Apache side...)


Any ideas or hints?



Joachim





Am 30.03.21 um 14:54 schrieb Esteban Maringolo:
On Tue, Mar 30, 2021 at 6:51 AM Sven Van Caekenberghe [hidden email] wrote:
I would try to look at WAFileHandler, which is responsible for serving the files.
I thought about the same approach.

1. Implement some WARestrictedFileHandler subclass of WAFileHandler,
where you configure (via a preference or plain instVar) the identifier
of the app that has the session registry (e.g. 'myApp')
2. In the handleFiltered: you get a reference to that WAApplication
and then you do something like:

handleFiltered: aRequestContext
  | app key session |
  app := WAAdmin defaultDispatcher handlerAt: 'myApp'.
  key := app trackingStrategy keyFromContext: aRequestContext.
  key isNil
    ifTrue: [ "generate the 403 response" ]
    ifFalse: [
     session := app cache at: key ifAbsent: [ nil ].
     session isNil
       ifTrue: [ "generate 403" ]
       ifFalse: [ ("check whether session is valid" ) ifTrue: [^super
handleFiltered: aRequestContext] ifFalse: ["403..."]
    ]
]

So the approach is to externally access the app session registry and
fetch the session from there.

What is not clear to me is whether you want to restrict access to
regular Seaside FileLibraries or to some other mapping to static files
in a filesystem.

Regards,

Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: A session-aware kind of FileLibrary - how/where to start

Annick
Hi Joachim,

I just discovered it by navigating the registries

Annick

Le 13 avr. 2021 à 11:03, [hidden email] a écrit :

Hi Annick,


thanks a lot for this information. Would've saved my sunday ;-)
I tried a few "something"s in that direction but failed, so I ended up rewriting the whole thing to using WADocumentHandler. I am happy with the results for now, but there is a feeling of "maybe it is not going to be flexible enough in the future". So it is good to know this. I liked the way a WAFileHandler worked in my dev image.

I wonder where/how you found this info?


Joachim






Am 12.04.21 um 09:51 schrieb List:
Hi Joachim,


You can register your files in a composite url by using 2 steps  (for instance clubs/fichiers)

(Seaside.WAAdmin defaultDispatcher handlers at: 'clubs')
        register: Seaside.WAFileHandler default
        at: 'fichiers’.

Annick

Le 11 avr. 2021 à 14:11, [hidden email] a écrit :

I solved the problem differently, because this was going to be complicated...

I just found that WADocumentHandler is quite exactly what I was looking for. It even has a few advantages for my use case: it doesn't even need to transport any information about the file to the Browser, it just renders a  _d parameter and is only valid within the session. A pity that I overlooked this at my first attempt to solve the problem. It took me a few hours to rewrite things and now I have what I wanted: I can serve files which have no guessable URLs and can only be served within a session.

It also solves the Apache Load Balancer problem, because the IMG or A paramters are URLs within /MyApp, just like any other component. So no need to register it in any location that can be handled correctly by mod_proxy_balancer and stuff.


Thanks for listening and have a nice rest-of-the-weekend!


Joachim





Am 11.04.21 um 07:45 schrieb [hidden email]:
Esteban,


I used your suggestion and it works very nicely. In development ;-)

Here are 2 things I encountered in a deployed image

  1. If the _s parameter is not the first one in the URL, the tracking Strategy will always return a nil key. Not sure why, especially in the light of the fact that this works fine in a dev image
  2. I have troubles getting things to work behind a load-balancing Apache because of the path. This one is really critical to me, let me explain:

I have configured Apache with mod_proxy_balancer to distribute load in sticky sessions to a few images who all listen to localhost:xxxx/MyApp. Since my Pseudo-FileLibrary needs the session context, it is necessary that all traffic of a session goes to the same image. So far, so well-known and logical.

The trouble is: my Application ist registered at: /MyApp, while the Pseudo-FileLibrary is registered at: /documents

This means that Apache mod_proxy_balancer will redirect all requests that get sent to https://mydomain/documents to https://mydomain/MyApp, which means a link or img tag points to the login page instead of a document served by my Pseudo File Library. The Pseudo File Library never gets to see a request...

I couldn't find a way to register a WARequestHandler subclass as a sub-path of a registered App. Because what I need is to register my Handler at /MyApp/documents.

WAAdmin register: MyHandler at: 'MyApp/documents'

throws an error: MyHandler doesNotUnderstand: key:.


So: how can I register a WARequestHandler at a subpath like /MyApp/documents?
Or, alternatively: how can I redirect incoming requests for /MyApp/documents to /documents within my image? (It seems hard to impossible to configure this on the Apache side...)


Any ideas or hints?



Joachim





Am 30.03.21 um 14:54 schrieb Esteban Maringolo:
On Tue, Mar 30, 2021 at 6:51 AM Sven Van Caekenberghe [hidden email] wrote:
I would try to look at WAFileHandler, which is responsible for serving the files.
I thought about the same approach.

1. Implement some WARestrictedFileHandler subclass of WAFileHandler,
where you configure (via a preference or plain instVar) the identifier
of the app that has the session registry (e.g. 'myApp')
2. In the handleFiltered: you get a reference to that WAApplication
and then you do something like:

handleFiltered: aRequestContext
  | app key session |
  app := WAAdmin defaultDispatcher handlerAt: 'myApp'.
  key := app trackingStrategy keyFromContext: aRequestContext.
  key isNil
    ifTrue: [ "generate the 403 response" ]
    ifFalse: [
     session := app cache at: key ifAbsent: [ nil ].
     session isNil
       ifTrue: [ "generate 403" ]
       ifFalse: [ ("check whether session is valid" ) ifTrue: [^super
handleFiltered: aRequestContext] ifFalse: ["403..."]
    ]
]

So the approach is to externally access the app session registry and
fetch the session from there.

What is not clear to me is whether you want to restrict access to
regular Seaside FileLibraries or to some other mapping to static files
in a filesystem.

Regards,

Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside