design question: sessions vs arguments

[julian_m]

i'm finishing my 2nd php project. It's a sort of catalog and I used
css/mysql as well. All the functionality of the site is mainly beacause
the great number of arguments I pass to every page on the address bar.
For example
*number of items to display
*categories
*brands
*user_id
*price interval
*...
*...
Note that the arguments aren't editable, beacause I've implemented a
sort of extra verifier argument which works quite well

The question is:
In order to achieve a good design and therefore a good product, should
I have to use session variables instead, or is it just a way to do the
same?

I would like to begin my next project with the right choice...

regards - jm

[David Haynes]

Re: design question: sessions vs arguments

julian_m wrote:[color=blue]
> i'm finishing my 2nd php project. It's a sort of catalog and I used
> css/mysql as well. All the functionality of the site is mainly beacause
> the great number of arguments I pass to every page on the address bar.
> For example
> *number of items to display
> *categories
> *brands
> *user_id
> *price interval
> *...
> *...
> Note that the arguments aren't editable, beacause I've implemented a
> sort of extra verifier argument which works quite well
>
> The question is:
> In order to achieve a good design and therefore a good product, should
> I have to use session variables instead, or is it just a way to do the
> same?
>
> I would like to begin my next project with the right choice...
>
> regards - jm
>[/color]
Sessions, when they are used this way, implement another level of
'security through obscurity'. That is they make it just a little bit
harder to see what data is being passed back and forth. If you are not
using cookie-based sessions, the obscurity factor goes up again.

Sessions also prevent the issue of cutting and pasting the URL into a)
multiple browsers or b) as bookmarks. While you can detect edits to your
argument data, can you detect replays? If not, you may have an issue.

I try to hide as much information from the browser as I can simply
because what they can't see, they can't futz around with ;-)

-david-

[Chung Leong]

Re: design question: sessions vs arguments

julian_m wrote:[color=blue]
> In order to achieve a good design and therefore a good product, should
> I have to use session variables instead, or is it just a way to do the
> same?[/color]

Don't do it. Using session variables to somehow hide GET variables
cause major navigation issues when visitors view your site in multiple
tabs/windows.

[julian_m]

Re: design question: sessions vs arguments


Chung Leong wrote:[color=blue]
> julian_m wrote:[color=green]
> > In order to achieve a good design and therefore a good product, should
> > I have to use session variables instead, or is it just a way to do the
> > same?[/color]
>
> Don't do it. Using session variables to somehow hide GET variables
> cause major navigation issues when visitors view your site in multiple
> tabs/windows.[/color]

That is one of the reasons why I work "hiper"polulati ng the address
bar, even though it isn't beautiful at all.

David seems to have another opinion though. I was sure it will be the
beginnig of the war ;)

regards - jm

[julian_m]

Re: design question: sessions vs arguments


David Haynes wrote:[color=blue]
> While you can detect edits to your
> argument data, can you detect replays?[/color]

Well, actually, I could. Just adding inside the argument verifier (md5)
the date it was created, and comparing it agaist the server date.
Nothing brillant, just an idea...

saludos - julian

[Carl]

Re: design question: sessions vs arguments

Chung Leong wrote:[color=blue]
> julian_m wrote:
>[color=green]
>>In order to achieve a good design and therefore a good product, should
>>I have to use session variables instead, or is it just a way to do the
>>same?[/color]
>
>
> Don't do it. Using session variables to somehow hide GET variables
> cause major navigation issues when visitors view your site in multiple
> tabs/windows.
>[/color]

Like already being logged in when you browse the same site in another
window or tab? I would think thats a good thing.

My advice would be the opposite, don't pass data in the URL unless you
have a good reason to, and there often are good reasons.

I wouldn't suggest you set a product category in a session, but for the
user info, #items/page, etc there is no reason to pass it in the url,
and reasons why it would be beneficial to have it in the session.
Think which items should apply to the users "session", and which should
apply to individual instances (browser windows/tabs) of the session.

Cheers,
Carl.

[David Haynes]

Re: design question: sessions vs arguments

julian_m wrote:[color=blue]
> David Haynes wrote:[color=green]
>> While you can detect edits to your
>> argument data, can you detect replays?[/color]
>
> Well, actually, I could. Just adding inside the argument verifier (md5)
> the date it was created, and comparing it agaist the server date.
> Nothing brillant, just an idea...
>
> saludos - julian
>[/color]
Hmmm...
I don't see how that would work.
You'd send out a page to a browser with an encoded timestamp.
It would send back some $_GET data presumably with the timestamp returned.
Somehow you would do delta on the timestamp to determine whether this
was a replay???

The usual way to do this is to hand a sequential number to the page
which, in turn, hands it back. The sequential number is then marked as
'processed' and all subsequent returns of the number are invalidated.

-david-

[Chung Leong]

Re: design question: sessions vs arguments

Carl wrote:[color=blue]
> Like already being logged in when you browse the same site in another
> window or tab? I would think thats a good thing.[/color]

I assure you that those who use the feature are very much dependent on
it. When I reply to posts on Google Group, for example, I frequently
would flip back to the previous screen in a different so I can see
what's been said already. On occasions I would open still another tab
when I want to cite a previous thread.
[color=blue]
> My advice would be the opposite, don't pass data in the URL unless you
> have a good reason to, and there often are good reasons.[/color]

It really isn't a matter of making a choice between GET and session.
It's about using something in the manner that it's designed for.
Session variables are designed for persistency. If that's what the
situation calls for, then use them. If not, then use something better
suited.

HTTP is a stateless protocol (by and large). A GET operation is
understood to be side-effect-less (i.e. read-only). When you stuff URL
parameters into the session, you're violating this basic assumption,
and predictably, bad things happen: bookmarking goes bust, tab-browsing
behaves weirdly, search engines can't spider your site, etc.

[Chung Leong]

Re: design question: sessions vs arguments

I forgot to list "the inability to utilitize page caching," which is a
serious minus when you care anything about scalability.

[Carl]

Re: design question: sessions vs arguments

Chung Leong wrote:[color=blue]
> Carl wrote:
>[color=green]
>>Like already being logged in when you browse the same site in another
>>window or tab? I would think thats a good thing.[/color]
>
>
> I assure you that those who use the feature are very much dependent on
> it. When I reply to posts on Google Group, for example, I frequently
> would flip back to the previous screen in a different so I can see
> what's been said already. On occasions I would open still another tab
> when I want to cite a previous thread.[/color]

Did you have to log in again when you opened a new tab? The OP made a
comment about passing, among other things, a "user_id" in the url. I am
suggesting this in more appropriately placed in the session.
[color=blue]
>
>[color=green]
>>My advice would be the opposite, don't pass data in the URL unless you
>>have a good reason to, and there often are good reasons.[/color]
>
>
> It really isn't a matter of making a choice between GET and session.
> It's about using something in the manner that it's designed for.
> Session variables are designed for persistency. If that's what the
> situation calls for, then use them. If not, then use something better
> suited.
>[/color]

It sounds to me like you're saying you should use GET unless its a
persistent value, I say don't use get unless it's NOT a persistent value.
Tomatoe, Potatoe :)
[color=blue]
> HTTP is a stateless protocol (by and large). A GET operation is
> understood to be side-effect-less (i.e. read-only). When you stuff URL
> parameters into the session, you're violating this basic assumption,
> and predictably, bad things happen: bookmarking goes bust, tab-browsing
> behaves weirdly, search engines can't spider your site, etc.
>[/color]

I may not have made myself clear, though i am pretty sure we are arguing
the same point here. You mention handling "URL parameters", and I gave a
suggestion on how to determine what constitutes is a "URL parameter".
Most posts before mine seemed to give a yes/no type answer, I was simply
_attempting_ to suggest that it is not as simple as that, and that
different the different problems require different solutions.

I replied to your post in which you said :
[color=blue]
> Don't do it. Using session variables to somehow hide GET variables
> cause major navigation issues when visitors view your site in multiple
> tabs/windows.[/color]

And i suggested that passing the user_id in the url would require you to
log back in if you navigate back to the site in another browser/tab.
*Broken*, IMHO.

Cheers.
Carl.

[Chung Leong]

Re: design question: sessions vs arguments

Carl wrote:[color=blue]
> It sounds to me like you're saying you should use GET unless its a
> persistent value, I say don't use get unless it's NOT a persistent value.
> Tomatoe, Potatoe :)[/color]

Well, that's a pretty amazing conclusion, consider that your comment
was "my advise would be the opposite." In any event, what I was saying
must have made better sense, as it doesn't involve a double negation.
[color=blue]
> And i suggested that passing the user_id in the url would require you to
> log back in if you navigate back to the site in another browser/tab.
> *Broken*, IMHO.[/color]

And your suggestion would be wrong. If the user_id is in the URL then
it would obviously be retained when you navigate to it in a new tab.