<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Esteban,</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">I used your suggestion and it works
      very nicely. In development ;-)</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Here are 2 things I encountered in a
      deployed image</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">
      <ol>
        <li>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>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>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">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>The trouble is: my Application ist registered at: <font
          face="monospace">/MyApp</font>, while the Pseudo-FileLibrary
        is registered at: <font face="monospace">/documents</font></p>
      <p>This means that Apache mod_proxy_balancer will redirect all
        requests that get sent to <font face="monospace"><a class="moz-txt-link-freetext" href="https://mydomain/documents">https://mydomain/documents</a>
        </font>to <font face="monospace"><a class="moz-txt-link-freetext" href="https://mydomain/MyApp">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>
      </p>
      <p>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>
      </p>
      <p><font face="monospace">WAAdmin register: MyHandler at:
          'MyApp/documents' </font><br>
      </p>
      <p>throws an error: <font face="monospace">MyHandler
          doesNotUnderstand: key:.</font></p>
    </div>
    <div class="moz-cite-prefix"><br>
    </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">/MyApp/documents</font>
      to <font face="monospace">/documents</font> within my image? (It
      seems hard to impossible to configure this on the Apache side...)<br>
      <p><br>
      </p>
      <p>Any ideas or hints?</p>
      <p><br>
      </p>
      <p><br>
      </p>
      <p>Joachim<br>
      </p>
      <p><br>
      </p>
      <p><br>
      </p>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Am 30.03.21 um 14:54 schrieb Esteban
      Maringolo:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJMgPCKaoDL=koM_HchCC-BJPJg2qb34Q+xPPRWebP=GkV2rrA@mail.gmail.com">
      <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"><sven@stfx.eu></a> wrote:
</pre>
      <blockquote type="cite">
        <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">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><br>
    </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>
  </body>
</html>