<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Joachim,<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>You can register your files in a composite url by using 2 steps (for instance clubs/fichiers)</div><div class=""><br class=""></div><div class="">(Seaside.WAAdmin defaultDispatcher handlers at: 'clubs')<br class=""> register: Seaside.WAFileHandler default<br class=""> at: 'fichiers’.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Annick<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 11 avr. 2021 à 14:11, <a href="mailto:jtuchel@objektfabrik.de" class="">jtuchel@objektfabrik.de</a> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">I solved the problem differently, because this was going to be
complicated...</p><p class="">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. <br class="">
</p><p class="">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. <br class="">
</p><p class=""><br class="">
</p><p class="">Thanks for listening and have a nice rest-of-the-weekend!</p><p class=""><br class="">
</p><p class="">Joachim<br class="">
</p><p class=""><br class="">
</p><p class=""><br class="">
</p>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">Am 11.04.21 um 07:45 schrieb
<a class="moz-txt-link-abbreviated" href="mailto:jtuchel@objektfabrik.de">jtuchel@objektfabrik.de</a>:<br class="">
</div>
<blockquote type="cite" cite="mid:d216e014-3ccb-d8bf-4434-9577ed68cf31@objektfabrik.de" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="moz-cite-prefix">Esteban,</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">I used your suggestion and it works
very nicely. In development ;-)</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">Here are 2 things I encountered in a
deployed image</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">
<ol class="">
<li class="">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</li>
<li class="">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:</li>
</ol><p class="">I have configured Apache with mod_proxy_balancer to
distribute load in sticky sessions to a few images who all
listen to <font face="monospace" class="">localhost:xxxx/MyApp</font>.
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.</p><p class="">The trouble is: my Application ist registered at: <font face="monospace" class="">/MyApp</font>, while the Pseudo-FileLibrary
is registered at: <font face="monospace" class="">/documents</font></p><p class="">This means that Apache mod_proxy_balancer will redirect all
requests that get sent to <font face="monospace" class=""><a class="moz-txt-link-freetext" href="https://mydomain/documents" moz-do-not-send="true">https://mydomain/documents</a>
</font>to <font face="monospace" class=""><a class="moz-txt-link-freetext" href="https://mydomain/MyApp" moz-do-not-send="true">https://mydomain/MyApp</a></font>,
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...<br class="">
</p><p class="">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. <br class="">
</p><p class=""><font face="monospace" class="">WAAdmin register: MyHandler at:
'MyApp/documents' </font><br class="">
</p><p class="">throws an error: <font face="monospace" class="">MyHandler
doesNotUnderstand: key:.</font></p>
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">So: how can I register a
WARequestHandler at a subpath like /MyApp/documents?</div>
<div class="moz-cite-prefix">Or, alternatively: how can I redirect
incoming requests for <font face="monospace" class="">/MyApp/documents</font>
to <font face="monospace" class="">/documents</font> within my image?
(It seems hard to impossible to configure this on the Apache
side...)<br class=""><p class=""><br class="">
</p><p class="">Any ideas or hints?</p><p class=""><br class="">
</p><p class=""><br class="">
</p><p class="">Joachim<br class="">
</p><p class=""><br class="">
</p><p class=""><br class="">
</p>
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">Am 30.03.21 um 14:54 schrieb Esteban
Maringolo:<br class="">
</div>
<blockquote type="cite" cite="mid:CAJMgPCKaoDL=koM_HchCC-BJPJg2qb34Q+xPPRWebP=GkV2rrA@mail.gmail.com" class="">
<pre class="moz-quote-pre" wrap="">On Tue, Mar 30, 2021 at 6:51 AM Sven Van Caekenberghe <a class="moz-txt-link-rfc2396E" href="mailto:sven@stfx.eu" moz-do-not-send="true"><sven@stfx.eu></a> wrote:
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">I would try to look at WAFileHandler, which is responsible for serving the files.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:seaside@lists.squeakfoundation.org" moz-do-not-send="true">seaside@lists.squeakfoundation.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" moz-do-not-send="true">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a>
</pre>
</blockquote><p class=""><br class="">
</p>
<pre class="moz-signature" cols="72">--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel <a class="moz-txt-link-freetext" href="mailto:jtuchel@objektfabrik.de" moz-do-not-send="true">mailto:jtuchel@objektfabrik.de</a>
Fliederweg 1 <a class="moz-txt-link-freetext" href="http://www.objektfabrik.de/" moz-do-not-send="true">http://www.objektfabrik.de</a>
D-71640 Ludwigsburg <a class="moz-txt-link-freetext" href="http://joachimtuchel.wordpress.com/" moz-do-not-send="true">http://joachimtuchel.wordpress.com</a>
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
</pre>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
seaside mailing list
<a class="moz-txt-link-abbreviated" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a>
</pre>
</blockquote><p class=""><br class="">
</p>
<pre class="moz-signature" cols="72">--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel <a class="moz-txt-link-freetext" href="mailto:jtuchel@objektfabrik.de">mailto:jtuchel@objektfabrik.de</a>
Fliederweg 1 <a class="moz-txt-link-freetext" href="http://www.objektfabrik.de/">http://www.objektfabrik.de</a>
D-71640 Ludwigsburg <a class="moz-txt-link-freetext" href="http://joachimtuchel.wordpress.com/">http://joachimtuchel.wordpress.com</a>
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
</pre>
</div>
_______________________________________________<br class="">seaside mailing list<br class=""><a href="mailto:seaside@lists.squeakfoundation.org" class="">seaside@lists.squeakfoundation.org</a><br class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br class=""></div></blockquote></div><br class=""></div></body></html>