A session-aware kind of FileLibrary - how/where to start
Locked
 
|
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 |
Re: A session-aware kind of FileLibrary - how/where to start
|
|
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 |
|
|
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. SvenOn 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 |
Re: A session-aware kind of FileLibrary - how/where to start
|
|
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:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: A session-aware kind of FileLibrary - how/where to start
|
|
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 |
Re: A session-aware kind of FileLibrary - how/where to start
|
|
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 |
|
|
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:
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:
-- ----------------------------------------------------------------------- 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 |
|
|
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 |
Re: A session-aware kind of FileLibrary - how/where to start
|
|
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:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: A session-aware kind of FileLibrary - how/where to start
|
|
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? 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
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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
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.
-- ----------------------------------------------------------------------- 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 |
|
|
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]:
-- ----------------------------------------------------------------------- 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 |
|
|
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
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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,
-- ----------------------------------------------------------------------- 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 |
|
|
Hi Joachim,
I just discovered it by navigating the registries Annick
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |