Session HELP !

[Bob Bedford]

In the attempt to keep the URL and code quite clean, and avoid to have a
very loooong url, we have used $_session[] for storing values trough the
pages.

Now, we have some clients that doesn't get any result when going on the
second page. After studying their browser, the confidentiality setting was
at the maximum. On their settings, the site doesn't work well.

Since we can't change the setting for every client, what may we do ?

For passing session variable does it suffice to put a .SID at the end of
every URL as we didn't do it.

And for POST submission, where we want to keep some values, how to we put a
SID at the form tag ?

Bob

[Gordon Burditt]

>In the attempt to keep the URL and code quite clean, and avoid to have a

very loooong url, we have used $_session[] for storing values trough the
pages.

Now, we have some clients that doesn't get any result when going on the
second page. After studying their browser, the confidentiality setting was
at the maximum. On their settings, the site doesn't work well.
This probably means that session cookies are not accepted.
Sessions require passing the session ID around, and the
existing choices are (a) cookie or (b) URL.
Since we can't change the setting for every client, what may we do ?

For passing session variable does it suffice to put a .SID at the end of
every URL as we didn't do it.
You need to pass the SID somehow, and that's one way. Also look
at trans_sid, which may do much the same thing but save you some
work. It puts the session ID in the URL unless it appears that
cookies are working.
And for POST submission, where we want to keep some values, how to we put a
SID at the form tag ?

Hidden field with the SID in it?

Gordon L. Burditt

[Chung Leong]

Bob Bedford wrote:

In the attempt to keep the URL and code quite clean, and avoid to have a
very loooong url, we have used $_session[] for storing values trough the
pages.

I would just take the time and remove this "feature" of yours and go
back to using GET variable. A site that's unbookmarkable is far more
annoying to end-users than long URLs. Add to that the inability for
Google to properly index your site and strange behavior with new
window, the aesthetic gain isn't worth it.

[Bob Bedford]

"Chung Leong" <ch***********@ hotmail.com> a écrit dans le message de news:
11************* ********@g43g20 00...legro ups.com...

Bob Bedford wrote:

In the attempt to keep the URL and code quite clean, and avoid to have a
very loooong url, we have used $_session[] for storing values trough the
pages.

I would just take the time and remove this "feature" of yours and go
back to using GET variable. A site that's unbookmarkable is far more
annoying to end-users than long URLs. Add to that the inability for
Google to properly index your site and strange behavior with new
window, the aesthetic gain isn't worth it.

In fact the session variable is also used to avoid worring about such GET or
POST variables.
Let's explain: the user make a search about a shoe make.
Then he looks trough the results, changing some pages, going inside articles
to see details, and so on, then want to perform an other search.
At every page, I've to worry about 10-20 variables every time. Putting them
in a session variable, I may ask the variable when needed, without worring
if I passed between all pages. For this I created a bounch of functions to
store and retrieve variable very easely, and it's a pain saving as you don't
forget to pass variables between pages.

That's the main reason we used sessions variable. We don't need to worry
about bookmarking such pages, as they are dynamic. We may use UrlRewrite
later for such needs (altrough we didn't look at this function yet)
Also for Google, we provided a sitemap in order to get all articles without
the need to worry about dynamic pages.

I am wrong ? any advice would greately be appreciated.

Bob

[Chung Leong]

Bob Bedford wrote:

In fact the session variable is also used to avoid worring about such GET or
POST variables.
Let's explain: the user make a search about a shoe make.
Then he looks trough the results, changing some pages, going inside articles
to see details, and so on, then want to perform an other search.
At every page, I've to worry about 10-20 variables every time. Putting them
in a session variable, I may ask the variable when needed, without worring
if I passed between all pages. For this I created a bounch of functions to
store and retrieve variable very easely, and it's a pain saving as you don't
forget to pass variables between pages.
Well, the pain of passing variables between pages is less than that of
dealing with session issues. If you bundle the search criteria in an
associative array, appending them to a URL isn't that hard.

I'm mentioning this because I use Firefox's tabs extensively. Given a
list of search results I'd almost inevitably center-click on the items
of interest to view them in separate tabs (so I can quickly jump
between them). Using session for passing variables would lead to very
odd behaviors in this scenario.
That's the main reason we used sessions variable. We don't need to worry
about bookmarking such pages, as they are dynamic.
Just because the pages are dynamically generated doesn't imply that
visitors wouldn't want to bookmark them. Also keep in mind that browse
history functions as an automatic bookmarking mechanism. It's quite
reasonable for someone to want to return to a search done on an earlier
day. Having to reenter the 10/20 parameters you mentioned would be
quite annoying.
I am wrong ? any advice would greately be appreciated.

In programming you usually want to avoid side-effects as much as
possible. You don't want the outcome of an operation to be dependent,
implicitly, on the effects of earlier operations. Passing variable
using sessions mean that the HTTP requests have to arrive in a
particular order. It's not a thing that you should depend on, as you
have no control over the browser or the end-user.

[Joseph S.]

> Well, the pain of passing variables between pages is less than that of

dealing with session issues. If you bundle the search criteria in an
associative array, appending them to a URL isn't that hard.

I'm mentioning this because I use Firefox's tabs extensively. Given a
list of search results I'd almost inevitably center-click on the items
of interest to view them in separate tabs (so I can quickly jump
between them). Using session for passing variables would lead to very
odd behaviors in this scenario.

I was taking the line Bob was - sessions for better security - till I
read your explanation about why GET is useful - bookmarking, users not
repeating searches etc. Very correct,indeed. But people learn how to
rewrite urls quite easily these days. For example you will have so many
people writing
http://www.google.com/search?my+search+term&hl=en while referring to
specific searches. How does one handle security in such cases. Yes,
encypted cookies stored on the users computer seem to be the best. Am I
right here?(or are there loopholes here as well?) What I can make out
from the two counterpoints is that if you have a section of your site
that gives just information and users need to enter parameters (and
naturally, returning users need to remember searches and bookmark
pages), use GET for that section, whereas, for the section where you
have to accept payments, use POSTs. What do you think?

Also, I have a related problem: even for a POST, Firefox(which is my
favorite as well) displays
http://mysite.com/myfile.php?PHPSESS...8a0b096bb73d05
in the URL which is disturbing to say the least after you've spent a
lot of time making a session-oriented application.
What do you to prevent that?

Open to ideas and suggestions,
Regards,
Joseph S.

[Gordon Burditt]

>In fact the session variable is also used to avoid worring about such GET or

POST variables.
Let's explain: the user make a search about a shoe make.
If the user is searching for a shoe make, he might want to bookmark
one of the results so he can come back to it later (perhaps he's
comparison shopping with other sites).
Then he looks trough the results, changing some pages, going inside articles
to see details, and so on, then want to perform an other search.
At every page, I've to worry about 10-20 variables every time. Putting them
in a session variable, I may ask the variable when needed, without worring
if I passed between all pages. For this I created a bounch of functions to
store and retrieve variable very easely, and it's a pain saving as you don't
forget to pass variables between pages.

That's the main reason we used sessions variable. We don't need to worry
about bookmarking such pages, as they are dynamic.
You do need to worry about bookmarking such pages, especially if
you're selling something. If the user can't come back to the page,
you may lose a sale. Now, some things shouldn't be bookmarked (like
a customer's list of what's currently in his shopping basket, or a
partially-completed order, or a map to the store based on the
customer's location), but pages for individual items for sale should
be bookmarkable.

"dynamic pages" are usually an implementation detail. If the
contents of the page depends on things like the item number, search
terms, category, etc. and not on the customer's ID number, customer's
password, or customer's geographic location, chances are it should
be bookmarkable.
We may use UrlRewrite
later for such needs (altrough we didn't look at this function yet)
Also for Google, we provided a sitemap in order to get all articles without
the need to worry about dynamic pages.

Gordon L. Burditt

[Joseph S.]

> You do need to worry about bookmarking such pages, especially if

you're selling something. If the user can't come back to the page,
you may lose a sale. Now, some things shouldn't be bookmarked (like
a customer's list of what's currently in his shopping basket, or a
partially-completed order, or a map to the store based on the
customer's location), but pages for individual items for sale should
be bookmarkable.

One other idea that naturally follows is that you can provide visitors
with a "mark as favorite" option or a "store my search" (a prominent
check box) and store a cookie on the user's computer and an entry in
your database (or maybe a php page explicitly for stored searches which
will read the cookie from his computer and direct him to the product
that he searched for after some processing). So it is only one page
that has to do with GET and without POST.
However, I feel it may be better still to design out all the pages and
separate out the GET and POST pages and keep them independent - e.g.
your catalog pages all are
http://www.mystore.com/catalog?cat=56&prod_id=65 etc. and your payment
and customer details and payment details pages are all POST.

One security related question: in Apache, how good is the idea of
mapping Aliases for php pages?
e.g.
I make an entry in httpd.conf for
Alias /store C:/Apache2/htdocs/store/displayall.php
and always use the header function like this
header("Locatio n: /store");
or
header("Locatio n: http://www.mysite.com/store");

will it be of any help for security?

BTW, can the Alias entry be put in a .htaccess file?

Joseph S.

[Chung Leong]

Joseph S. wrote:

I was taking the line Bob was - sessions for better security - till I
read your explanation about why GET is useful - bookmarking, users not
repeating searches etc. Very correct,indeed. But people learn how to
rewrite urls quite easily these days.

I disagree with the notion that using session to pass variable lead to
better security. If access to a resource identified by a GET parameter
requires proper authorization, then just perform the necessary
authorization checks within that page. That simplifies the security
analysis: if the checks occur, then the resource is safe. In constrast,
when you rely on the user's inability to alter session variables for
security, the analysis is more complicate: the resource is safe only if
the user cannot somehow use other pages to set the session variables to
illegal values. You end up having to prove a negative.

Security by assertion is better than security by prevention. It's
easier to see that something happens correctly than to show that
nothing can go wrong.

[R. Rajesh Jeba Anbiah]

Chung Leong wrote:
<snip>

I'm mentioning this because I use Firefox's tabs extensively.

<snip>

Great news indeed; IIRC, you were a fan of IE:-). FWIW, I recently
found Tab Mix Plus <http://tmp.gary.elixan t.com/> extension is a very
nice piece of tool for FF tab browsing; might help to at least some.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/