Re: [cgiapp] CAP::Authentication & cookies

["Cees Hek" <suppressed>]

On 3/28/06, Ron Savage <suppressed> wrote:
> On Mon, 27 Mar 2006 21:49:54 -0500, Cees Hek wrote:
> > I mentioned that by default it works that way.  In other words, it
> > will only try to keep your session ID persistent using cookies.  If
> > you want to use another technique, then you have to do that side of
> > it manually (ie filling in IDs into every URL and form).  The
>
> Firstly let me say I never fiddle the URL, so no energy spent there.

Just curious here.  Is everything a POST request in your apps then?  I
would guess that any GET request would force you to dynamically build
those URLs.  How do you handle link menus?  Usually those are fairly
static URLs in my pages.

> So this 1 line:
>
>         $template -> param(sid => $self -> session() -> id() );
>
> does the job for all run modes. No energy spent there, either.

And one line in the template.

To be honest, for 90% of the links in my app it would be pretty
trivial for me to add the SID to the URL.  All of my apps have a 'url'
method that is used to generate URLs for the application.  Usually
that is used to build URLs to conform with CA::Dispatch, but it would
be trivial to get it to add the session ID in there as well.  So
typically in my templates I have things like this:

[% c.url( rm='view' id=product.id ) %]  => /myapp/store/view/4254

Or if there wasn't PATH_INFO mapping for that combination is would
just generate this as a default:

/myapp/store?rm=view&id=4254

And to make my apps portable I often create simple methods for other
types of URLs as well:

[% c.image_url( file='create_btn.png' ) %]  => /myapp/images/create_btn.gif

Which means I can place my app into sub directories without having to
change an URLs (ie I can change 'myapp' to 'babsuvula' and all the
URLs would still work correctly.

But this doesn't solve the 'static pages' problem with url based
session IDs.  Most of the time there are lots of links on the page
that go to static pages, and a click to a static page would loose the
session.  That is my biggest problem with URL/Form based sessions.

> > Just because there is more than one way, doesn't mean that some of
> > those ways are not kludges ;-)
>
> I'll concede no more than you've almost made a good point here!

:)

> > Sure, it is personal preference, and if the requirements came down
> > from the client that cookies were optional, but sessions were
> > required, then I would probably use the URL method (or some
> > mod_rewrite hacks).
>
> With my work, sessions are always required, and I see no point in spending
> energy on mod_rewrite.
>
> And anyway, how would that be less effort than adding a sid to a form? Hint:
> You're correct answer is: No less effort, actually :-)).

Sure, but I wasn't arguing that.  mod_rewrite tricks have their own
problem (ie all links in your page have to be a relative URLs, which
causes havoc when you also use PATH_INFO)

> Well, let's at least agree on one thing: Don't use URL-based sessions without a
> exceedingly good reason. I've always felt it looked suspiciously like hard work,
> anyway.

Now you have slightly confused me.  Are you just advocating form based
sessions (ie using hidden fields)?  I thought that once you went down
that road you need to alter all URLs (in HREF links) as well.  Unless
everything in your app is a form request that is...

Anyway, I am not trying to convince people to only use cookies for
session management.  I just think that for me it is a lot of wasted
effort to worry about sticking a session ID into every URL and form
when I can set a cookie once and be done with it (and that cookie is
set for me by a plugin so I don't even have to worry about it myself).

Cheers,

Cees

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed