Re: [cgiapp] CAP::Authentication & cookies

[Ron Savage <suppressed>]

On Mon, 27 Mar 2006 21:49:54 -0500, Cees Hek wrote:

Hi Cees

> 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.

Secondly, adding a sid to every form takes 1 line, and no, I don't mean 1 line
per run mode, either.

Here's how I return from a typical run mode:

	my($content)	= $self -> load_tmpl('current.tmpl');

	$self -> toss_data_like_a_salad(...);

	return $self -> build_global_page
	({
		content	=> $content -> output(),
		rm		=> 'view_request_summary',
	});

and that specifies the next run mode of course. And the method called here is:

sub build_global_page
{
	my($self, $arg)	= @_;

	my($template)	= $self -> load_tmpl('global.tmpl');

	$template -> param($_ => $$arg{$_}) for keys %$arg;
	$template -> param(sid => $self -> session() -> id() );
	$template -> param(url => $self -> param('url') );

	return $template -> output();

}	# End of build_global_page.

So this 1 line:

	$template -> param(sid => $self -> session() -> id() );

does the job for all run modes. No energy spent there, either.

> 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 :-)).

> Nothing can be forced on the user.  The user always has the choice
> to decline cookies.  Or for that matter they can decline to view
> images, and decline to apply your CSS styles.  But if they come to
> me and complain that things aren't working, I will tell them to
> turn cookies on, and use my stylesheet instead of their own...  At
> that point they still have to option accept or decline.

Fair enuf.

> Using cookies does not require user intervention.  It works
> seemlessly.  The whole purpose of cookies is to provide a means of
> maintaining state in a stateless environment.  So why not use it?
> It only requires user intervention if the user chooses to be
> notified when cookies are set.  But that is a choice the user makes.

OK.

> I would posit that using URL based sessions is more of a hassle for
> the end user since there is no way to maintain a session across a
> browser restart short of creating a bookmark.  Also, as a developer
> you limit yourself to only using dynamic pages, since you can not
> send a user to a static page or they will loose their session (the
> static page will not have the sessionID embeded in it's links).

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.

--
Ron Savage
suppressed
http://savage.net.au/index.html



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