Seaside, some questions...

Hello.

Some friends of me and I thought about a new WEB-Site, and I might want
to implement it with gst and seaside, but therefore, I have some open
questions... (and maybe some more experienced user of gst and seaside
than me, could answer my questions here).

- How do you secure the config-site of seaside with - at minimum - a
user/password? (I tried a load into squeak, and it asked me for a
user/password combination, but where is it saved, that I could set it in
gst "by hand"? Or is it because of the difference between swazoo and
comanche. And if so, how do you workaround it.)

- Do you hide the /seaside/ path somehow for the user?

- Do you really need the halos for development? (And if so, how do you
activate them. I know the entry about seaside on
http://smalltalk.gnu.org, but I couldn't add something like
WAToolConfiguration to the configuration of my application. My page
looked like: http://up.picr.de/2368288.jpg

Would be nice to get some tipps from you.

Thanks in advance,
Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> - How do you secure the config-site of seaside with - at minimum - a
> user/password? (I tried a load into squeak, and it asked me for a
> user/password combination, but where is it saved, that I could set it in
> gst "by hand"? Or is it because of the difference between swazoo and
> comanche. And if so, how do you workaround it.)

It looks like this part is unimplemented in Swazoo, OTOH it seems pretty
easy to do (the HTTPAuthenticationChallenge class is missing).  (swazoo
list CCed).

I think what is often done, is to firewall Swazoo, and instead use
Apache as a proxy server.  You then configure Apache to block
/seaside/config and to use it, you access Swazoo directly (because of
the firewall, that would be possible only within some kind of DMZ).

 > - Do you hide the /seaside/ path somehow for the user?

If you want this, you have to make the root entry point the
WAApplication instead of using a WADispatcher as Seaside does by default.

> - Do you really need the halos for development? (And if so, how do you
> activate them. I know the entry about seaside on
> http://smalltalk.gnu.org, but I couldn't add something like
> WAToolConfiguration to the configuration of my application. My page
> looked like: http://up.picr.de/2368288.jpg

click Override in decoration classes. They are not necessary, but very
useful.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> - How do you secure the config-site of seaside with - at minimum - a
> user/password? (I tried a load into squeak, and it asked me for a
> user/password combination, but where is it saved, that I could set it in
> gst "by hand"? Or is it because of the difference between swazoo and
> comanche. And if so, how do you workaround it.)

It looks like this part is unimplemented in Swazoo, OTOH it seems pretty
easy to do (the HTTPAuthenticationChallenge class is missing).  (swazoo
list CCed).

I think what is often done, is to firewall Swazoo, and instead use
Apache as a proxy server.  You then configure Apache to block
/seaside/config and to use it, you access Swazoo directly (because of
the firewall, that would be possible only within some kind of DMZ).

 > - Do you hide the /seaside/ path somehow for the user?

If you want this, you have to make the root entry point the
WAApplication instead of using a WADispatcher as Seaside does by default.

> - Do you really need the halos for development? (And if so, how do you
> activate them. I know the entry about seaside on
> http://smalltalk.gnu.org, but I couldn't add something like
> WAToolConfiguration to the configuration of my application. My page
> looked like: http://up.picr.de/2368288.jpg

click Override in decoration classes. They are not necessary, but very
useful.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi Paolo,

thanks for your answer! :-)

> I think what is often done, is to firewall Swazoo, and instead use
> Apache as a proxy server.  You then configure Apache to block
> /seaside/config and to use it, you access Swazoo directly (because of
> the firewall, that would be possible only within some kind of DMZ).

To use apache as a reverse-proxy came (a bit) to my mind, in the
meantime. To have apache responsible for serving the static part of the
application, like images and css-files. (I read somewhere, that the
static-part should be usable with swazoo, but I found nowhere a bit more
detailed example, than the ones on the swazoo website which is only a
5-liner and serves the hello-world through an object. If you would now
somewhere a bit more detailed desription about swazoo, that would be nice.)
Nevertheless, I have to run apache on my server, for serving the other
site, so the proxy part is only an additional task for it and no reason
for an initial install of apache.
And maybe I can limit the access to swazoo only from localhost in this
case (I have to say, that I 'hate' the iptable-thing on linux, I'm a
much greater fan of the freebsd ipfw, but that's a bit OT here...)

>  > - Do you hide the /seaside/ path somehow for the user?
>
> If you want this, you have to make the root entry point the
> WAApplication instead of using a WADispatcher as Seaside does by default.

Maybe (I currently don't know, I have to try it first) this would also
be possible by using apache as a reverse-proxy...? (I'll see)

> click Override in decoration classes. They are not necessary, but very
> useful.

Ah great! :-D eventually it's working :-D
(I was a bit despaired about that, but now :-) everything is fine!)

Tomorow, I will take some time to tinker around a little bit with
seaside (and I'd like to prepare a new post about Gtk and TreeViews)

Thanks again! :-)

Joachim.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi guys,

Swazoo 1 has a workable HTTP Authentication-Basic implemented and used
in practice, while Digest one was almost implemented. Due to lack of
time it was not ported to a new request framework in Swazoo 2, but it
shouldn't be hard to do now.

If someone is interested, you can count on all my support, we also need
it in Aida/Web to put back to live its WebDAV support, which needs HTTP
Authentication too.

Best regards
Janko

Paolo Bonzini pravi:


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>>  > - Do you hide the /seaside/ path somehow for the user?
>>
>> If you want this, you have to make the root entry point the
>> WAApplication instead of using a WADispatcher as Seaside does by default.
>
> Maybe (I currently don't know, I have to try it first) this would also
> be possible by using apache as a reverse-proxy...? (I'll see)

Yes, of course.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk