[Q] On URL rewriting

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I want to use url like this "/app/appname/AAA/BBB" instead of default
one "/seaside/appname?_k=AAA&_s=BBB". Could this be done?

Thanks in advance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFdoPKQqspS1+XJHgRAgoYAKCQjtZaUnn0IKiADKBNXkeal2qZ7ACghBQB
mVKv7nRtZJ7sIufMPjVXVQc=
=+aB5
-----END PGP SIGNATURE-----
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi everyone,

I'm developping an application with Seaside for which I'm sending a
cookie using #redirectWithCookie: .
This application is deployed on 3 servers that share the same domain
name. I'de like the cookie to be attached to the domain, not to the
server. But I can't find a selector to specify the domain name.

How can I achieve this ?

Thanks a lot.


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

> I'm developping an application with Seaside for which I'm sending a
> cookie using #redirectWithCookie: .
> This application is deployed on 3 servers that share the same domain
> name. I'de like the cookie to be attached to the domain, not to the
> server. But I can't find a selector to specify the domain name.
>
> How can I achieve this ?

I don't think you can do this out of the box, but you can certainly
change the implementation by looking at #redirectWithCookie:

I guess this cookie-question is somehow related to your
Apache-Load-Balancing question, that I don't really get. I suggest not
to use cookies whenever possible (a lot of people have them disabled
anyway), but instead modify the generated URL. So if you want to tag
requests to go to a specific image I suggest to override #updateUrl:
in the root component and add a parameter identifying the image. Like
this you can also do the Apache rewriting easily.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2006/12/6, Vincent Girard-Reydet <[hidden email]>:
> Hi everyone,
>
> I'm developping an application with Seaside for which I'm sending a
> cookie using #redirectWithCookie: .
> This application is deployed on 3 servers that share the same domain
> name. I'de like the cookie to be attached to the domain, not to the
> server. But I can't find a selector to specify the domain name.
>
> How can I achieve this ?

I hope this can not be done. That would be a from of cross site
cookies. Very evil.

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

Lukas Renggli wrote:
My problem is that my application renders HTML content integrated inside
  iframes on another site maintained by our client (yes I know, frames
suck, but that's how it was specified). The application offers various
services that are invoked by the parent site at www.mydomain.com/service

The problem are:
  - www.mydomain.com doesn't always point to the same server (because of
round-robin DNS)
  - the various services must communicate (there's a notion of logged in
user common to all services)

I use a session cookie and other cookies to remember vital information,
but I can't manage to stick a client to one server once he has started a
session. That's why I wanted this domain cookie. I want to store the
name (or IP, or whatever) of the server that initialized the session, to
redirect the user to the correct server if he tries to open a session on
another one. But to do this I need a domain-wide cookie.

If someone has an idea on how to integrate a seaside site to another
site without IFRAMES, I'm open to any suggestions.

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

I don't think so, sharing a common cookie for a domain is not violating
anything, it's common practice.  He's not talking different domains, just
different servers within a domain, which is perfectly valid.

Ramon Leon
http://onsmalltalk.com 

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

>From looking at the implementation, WACookie would need to be enhanced to
support domains, it currently only supports name/value, expires, and path.

Ramon Leon
http://onsmalltalk.com 

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

2006/12/6, Ramon Leon <[hidden email]>:
Well if it's all for the same domain, then I hosetly fail to see the problem.

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

On 12/6/06, Philippe Marschall <[hidden email]> wrote:
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sungjin Chun wrote:
> I want to use url like this "/app/appname/AAA/BBB" instead of default
> one "/seaside/appname?_k=AAA&_s=BBB". Could this be done?

Certainly can be done, because the URLs used to look
just like that (back somewhere around version 2.3, I think).

Many users disliked these "scary" character strings that
would appear in the URL. Somehow, it's less scary when
these random strings appear in the querystring part.
There was all sorts of paranoid speculation on what
these URLs were hiding. It also made bookmarks cumbersome,
since they looked like different URLs in the browser history.

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

> I just want to echo what Philippe said. The cookie's domain
> will be set by what host name you typed into the browser to
> access the machine. So, for example, when I'm testing web
> apps at my office, they show up either as "localhost" or
> "round-robin-1" or similar, whereas everyone else would see
> them as e.g. foo.company.com, since their computer will
> access from public DNS. You shouldn't need to do anything on Seaside.
>
> --Benjamin

By default, when not explicitly set, the domain includes the host name, this
prevents the cookie from being accessed by other servers in the same domain.
You're correct that from the outside view, if they're all hitting
foo.company.com then this shouldn't be an issue.  

I'm just pointing out that Seaside is deficient in this area, not that it
applies to his problem.  Seaside can't currently allow a cookie to be shared
between web.foo.com and app.foo.com, even though they are both on the same
domain, because the implementation of WACookie is incomplete and doesn't
allow you to explicitly set the domain of a cookie, as most other web
frameworks would allow you to do.

Ramon Leon
http://onsmalltalk.com 

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

> I'm just pointing out that Seaside is deficient in this area, not that it
> applies to his problem.  Seaside can't currently allow a cookie to be shared
> between web.foo.com and app.foo.com, even though they are both on the same
> domain, because the implementation of WACookie is incomplete and doesn't
> allow you to explicitly set the domain of a cookie, as most other web
> frameworks would allow you to do.

Please feel free to add this functionality. The reason that WACookie
doesn't provide this functionality could be that nobody needed it ;-)

I never felt the need to use a cookie during 4 years of Seaside
experience. After all Seaside provides much nicer ways to remember
information between request than to use cookies. The only thing I can
think of were cookies could be useful are for evil things like
tracking people visiting the site.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Believe me, if I needed it, I would, but it's not an itch I need to scratch,
nor have time to at the moment.  I've never felt the need to use a cookie
either, I was just pointing it out so Vince didn't waste any time looking
for a feature that didn't exist.

Ramon Leon
http://onsmalltalk.com 

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

Well, cookies (if they worked properly) would be great for session
tracking, because without them one could copy the URL and paste it on
another machine to keep on working, which is a bit of a security risk,
for instance I can use my cell phone camera to take a pic of someone's
desktop, and type the same URL in my browser. I use session protector
for our app, but it's a tad useless in today's world full of networks
NAT'ed behind a single IP.

No?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Ramon
Leon
Sent: Wednesday, December 06, 2006 12:00 PM
To: 'The Squeak Enterprise Aubergines Server - general discussion.'
Subject: RE: RE: [Seaside] Adding domain to a cookie

Believe me, if I needed it, I would, but it's not an itch I need to
scratch,
nor have time to at the moment.  I've never felt the need to use a
cookie
either, I was just pointing it out so Vince didn't waste any time
looking
for a feature that didn't exist.

Ramon Leon
http://onsmalltalk.com 

_______________________________________________
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

On 12/6/06, Boris Popov <[hidden email]> wrote:
> Well, cookies (if they worked properly) would be great for session
> tracking, because without them one could copy the URL and paste it on
> another machine to keep on working, which is a bit of a security risk,
> for instance I can use my cell phone camera to take a pic of someone's
> desktop, and type the same URL in my browser. I use session protector
> for our app, but it's a tad useless in today's world full of networks
> NAT'ed behind a single IP.
>
> No?

Indeed.  There's an option (#useSessionCookie) to store the session ID
in a cookie.  Another advantage of this is that if the user closes
their browser window and then comes back to the app later just by
typing in the URL, they will get put back into their old session if it
hasn't expired.  The main disadvantage is that you can't have two
sessions on the same app from the same browser (it really annoys me
that I can't have two different gmail accounts open, for example).

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

Unless I'm wrong, Seaside will already use cookies for session tracking,
it's just not the default.  Seaside certainly does cookies, just doesn't
fully support the entire spec, i.e. no explicit domains.

Ramon Leon
http://onsmalltalk.com 

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

Try to visit the site with browser that has cookies disabled, you'll end
up in an endless loop of redirects. In all honestly, maybe I should have
spent some time and devised a fallback plan for when it happens to
switch that session to URL tracking, but haven't done it yet and
probably won't for a while :)

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Avi
Bryant
Sent: Wednesday, December 06, 2006 12:07 PM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: RE: RE: [Seaside] Adding domain to a cookie

On 12/6/06, Boris Popov <[hidden email]> wrote:
> Well, cookies (if they worked properly) would be great for session
> tracking, because without them one could copy the URL and paste it on
> another machine to keep on working, which is a bit of a security risk,
> for instance I can use my cell phone camera to take a pic of someone's
> desktop, and type the same URL in my browser. I use session protector
> for our app, but it's a tad useless in today's world full of networks
> NAT'ed behind a single IP.
>
> No?

Indeed.  There's an option (#useSessionCookie) to store the session ID
in a cookie.  Another advantage of this is that if the user closes
their browser window and then comes back to the app later just by
typing in the URL, they will get put back into their old session if it
hasn't expired.  The main disadvantage is that you can't have two
sessions on the same app from the same browser (it really annoys me
that I can't have two different gmail accounts open, for example).

Avi
_______________________________________________
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

On 12/6/06, Boris Popov <[hidden email]> wrote:
> Try to visit the site with browser that has cookies disabled, you'll end
> up in an endless loop of redirects. In all honestly, maybe I should have
> spent some time and devised a fallback plan for when it happens to
> switch that session to URL tracking, but haven't done it yet and
> probably won't for a while :)

Ah, yes, that problem.  I feel about the same way (should spend the
time, probably won't).  :)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yanni Chiu wrote:
> Sungjin Chun wrote:
>> I want to use url like this "/app/appname/AAA/BBB" instead of default
>> one "/seaside/appname?_k=AAA&_s=BBB". Could this be done?
>
> Certainly can be done, because the URLs used to look
> just like that (back somewhere around version 2.3, I think).
>

Thanks, then, I found that "seaside" is hard coded into WADispatcher.
Should I modify this class for "app"? And to modify other part of the
URL, what part should I refer? Thanks in advance,

> Many users disliked these "scary" character strings that
> would appear in the URL. Somehow, it's less scary when
> these random strings appear in the querystring part.
> There was all sorts of paranoid speculation on what
> these URLs were hiding. It also made bookmarks cumbersome,
> since they looked like different URLs in the browser history.

Oh, I, personally does not like query string... and I just want to try
this :-) and want to know how the url things could be modified.

Thanks again.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFd3PVQqspS1+XJHgRAiR3AKCKJ+IxFW6xK/kCcWUpO8Dne95nVQCggkhJ
g3dChURaDqR/3V56h+ZsQ18=
=Ci0/
-----END PGP SIGNATURE-----
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside