Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6236 > unrolled thread

sessions causing refreshing not to work

Back to article view | Back to comp.lang.php

Contents

  sessions causing refreshing not to work Michael Joel <null@void.void> - 2012-06-02 23:17 -0400
    Re: sessions causing refreshing not to work "Peter H. Coffin" <hellsop@ninehells.com> - 2012-06-02 22:57 -0500
      Re: sessions causing refreshing not to work Fred <fr-icsr@numericable.fr> - 2012-06-03 13:07 +0200
        Re: sessions causing refreshing not to work "Peter H. Coffin" <hellsop@ninehells.com> - 2012-06-03 22:20 -0500
      Re: sessions causing refreshing not to work Arno Welzel <usenet@arnowelzel.de> - 2012-06-04 07:56 +0200
        Re: sessions causing refreshing not to work "Peter H. Coffin" <hellsop@ninehells.com> - 2012-06-04 11:20 -0500
          Re: sessions causing refreshing not to work Arno Welzel <usenet@arnowelzel.de> - 2012-06-05 03:27 +0200
      Re: sessions causing refreshing not to work Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-05 06:46 +0200
        Re: sessions causing refreshing not to work "Peter H. Coffin" <hellsop@ninehells.com> - 2012-06-05 07:14 -0500
          Re: sessions causing refreshing not to work Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-05 20:52 +0200
            Re: sessions causing refreshing not to work "Peter H. Coffin" <hellsop@ninehells.com> - 2012-06-05 15:05 -0500
              Re: sessions causing refreshing not to work Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-06 21:50 +0200
          Re: sessions causing refreshing not to work Richard Damon <news.x.richarddamon@xoxy.net> - 2012-06-06 08:34 -0400
    Re: sessions causing refreshing not to work Fred <fr-icsr@numericable.fr> - 2012-06-03 13:21 +0200
      Re: sessions causing refreshing not to work Michael Joel <null@void.void> - 2012-06-03 09:59 -0400
        Re: sessions causing refreshing not to work Fred <fr-icsr@numericable.fr> - 2012-06-03 16:43 +0200
          Re: sessions causing refreshing not to work Denis McMahon <denismfmcmahon@gmail.com> - 2012-06-03 19:13 +0000
    Re: sessions causing refreshing not to work Arno Welzel <usenet@arnowelzel.de> - 2012-06-04 07:59 +0200
    Re: sessions causing refreshing not to work "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-06-04 09:12 +0200
    Re: sessions causing refreshing not to work Michael Joel <null@void.void> - 2012-06-05 16:51 -0400
      Re: sessions causing refreshing not to work The Natural Philosopher <tnp@invalid.invalid> - 2012-06-05 23:09 +0100

Page 1 of 2  [1] 2  Next page →

#6236 — sessions causing refreshing not to work

I have page data being sent through a php script that uses sessions to 
pass along variables. These vars are used to load data.

If a user opens a page, everything works fine.
If they open another in a new window it works fine.
If they tab back over to the original browser window and hit refresh it 
switches to the last page they opened in the other window.

This is because sessions is keeping that last var data in memory so the 
old page when refreshed reads the new var data and opens new data 
instead of refreshing the old.

How would I go about fixing this so a page doesn't lose it's var data on 
refresh?

Mike

[toc] | [next] | [standalone]

#6237

On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
> I have page data being sent through a php script that uses sessions to 
> pass along variables. These vars are used to load data.
>
> If a user opens a page, everything works fine.
> If they open another in a new window it works fine.
> If they tab back over to the original browser window and hit refresh it 
> switches to the last page they opened in the other window.
>
> This is because sessions is keeping that last var data in memory so the 
> old page when refreshed reads the new var data and opens new data 
> instead of refreshing the old.
>
> How would I go about fixing this so a page doesn't lose it's var data on 
> refresh?

Set session.use_trans_sid, unset session.use_cookie, don't forget to
grab the session ID out of the $_GET array for every page load. Yes,
your URLs will be ugly, and it'll be not impossible for someone to end
up screwing things somehow with URL bookmarking or sharing.

-- 
76. If the hero runs up to my roof, I will not run up after him and 
    struggle with him in an attempt to push him over the edge. I will 
    also not engage him at the edge of a cliff. (In the middle of a 
    rope-bridge over a river of lava is not even worth considering.)

[toc] | [prev] | [next] | [standalone]

#6238

Le 03/06/2012 05:57, Peter H. Coffin a écrit :

>
> Set session.use_trans_sid, unset session.use_cookie, don't forget to
> grab the session ID out of the $_GET array for every page load. Yes,
> your URLs will be ugly, and it'll be not impossible for someone to end
> up screwing things somehow with URL bookmarking or sharing.
>

session.use_trans_sid and session.use_cookie are 2 ways to manage
session but the result will be the same.

Fred

[toc] | [prev] | [next] | [standalone]

#6243

On Sun, 03 Jun 2012 13:07:20 +0200, Fred wrote:
> Le 03/06/2012 05:57, Peter H. Coffin a ?crit :
>
>>
>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>> grab the session ID out of the $_GET array for every page load. Yes,
>> your URLs will be ugly, and it'll be not impossible for someone to end
>> up screwing things somehow with URL bookmarking or sharing.
>>
>
> session.use_trans_sid and session.use_cookie are 2 ways to manage
> session but the result will be the same.

Allowing the use of something is not the same as forcing the use of
something. Either option can be allowed or disallowed independantly.
It's kind of important because the "default", the type that all the doco
talk about, is session via cookie. Session via $_GET is a bit more manual
(you have to fetch the SID explicitly), and the way that the
configuration stuff is set up allows for other means of store/fetching
session IDs, which may someday come along. 

-- 
22. No matter how tempted I am with the prospect of unlimited power, I 
   will not consume any energy field bigger than my head.
        --Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [next] | [standalone]

#6244

Peter H. Coffin, 03.06.2012 05:57:

> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>> I have page data being sent through a php script that uses sessions to 
>> pass along variables. These vars are used to load data.
>>
>> If a user opens a page, everything works fine.
>> If they open another in a new window it works fine.
>> If they tab back over to the original browser window and hit refresh it 
>> switches to the last page they opened in the other window.
>>
>> This is because sessions is keeping that last var data in memory so the 
>> old page when refreshed reads the new var data and opens new data 
>> instead of refreshing the old.
>>
>> How would I go about fixing this so a page doesn't lose it's var data on 
>> refresh?
> 
> Set session.use_trans_sid, unset session.use_cookie, don't forget to
> grab the session ID out of the $_GET array for every page load. Yes,
> your URLs will be ugly, and it'll be not impossible for someone to end
> up screwing things somehow with URL bookmarking or sharing.

Don't do this.

1) It won't change anything. The session itself will remain the same -
therefore it makes no sense to transmit the ID via the URL.

2) Adding session IDs to forms may destroy validity of the documents
(also see
<http://www.mtdev.com/2002/06/why-you-should-disable-phps-session-use_trans_sid>).



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6247

On Mon, 04 Jun 2012 07:56:49 +0200, Arno Welzel wrote:
> Peter H. Coffin, 03.06.2012 05:57:
>
>> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>>> I have page data being sent through a php script that uses sessions to 
>>> pass along variables. These vars are used to load data.
>>>
>>> If a user opens a page, everything works fine.
>>> If they open another in a new window it works fine.
>>> If they tab back over to the original browser window and hit refresh it 
>>> switches to the last page they opened in the other window.
>>>
>>> This is because sessions is keeping that last var data in memory so the 
>>> old page when refreshed reads the new var data and opens new data 
>>> instead of refreshing the old.
>>>
>>> How would I go about fixing this so a page doesn't lose it's var data on 
>>> refresh?
>> 
>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>> grab the session ID out of the $_GET array for every page load. Yes,
>> your URLs will be ugly, and it'll be not impossible for someone to end
>> up screwing things somehow with URL bookmarking or sharing.
>
> Don't do this.
>
> 1) It won't change anything. The session itself will remain the same -
> therefore it makes no sense to transmit the ID via the URL.

It WILL, though, mean that users can have separate sessions in different
tabs in the browser, which is the effect of the original problem that
was requested help with.

> 2) Adding session IDs to forms may destroy validity of the documents
> (also see
><http://www.mtdev.com/2002/06/why-you-should-disable-phps-session-use_trans_sid>).

Yup, there's tradeoffs for everything.

-- 
53. If the beautiful princess that I capture says "I'll never marry 
    you! Never, do you hear me, NEVER!!!", I will say "Oh well" and 
    kill her.
	--Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [next] | [standalone]

#6248

Peter H. Coffin, 04.06.2012 18:20:

> On Mon, 04 Jun 2012 07:56:49 +0200, Arno Welzel wrote:
>> Peter H. Coffin, 03.06.2012 05:57:
>>
>>> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>>>> I have page data being sent through a php script that uses sessions to 
>>>> pass along variables. These vars are used to load data.
>>>>
>>>> If a user opens a page, everything works fine.
>>>> If they open another in a new window it works fine.
>>>> If they tab back over to the original browser window and hit refresh it 
>>>> switches to the last page they opened in the other window.
>>>>
>>>> This is because sessions is keeping that last var data in memory so the 
>>>> old page when refreshed reads the new var data and opens new data 
>>>> instead of refreshing the old.
>>>>
>>>> How would I go about fixing this so a page doesn't lose it's var data on 
>>>> refresh?
>>>
>>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>>> grab the session ID out of the $_GET array for every page load. Yes,
>>> your URLs will be ugly, and it'll be not impossible for someone to end
>>> up screwing things somehow with URL bookmarking or sharing.
>>
>> Don't do this.
>>
>> 1) It won't change anything. The session itself will remain the same -
>> therefore it makes no sense to transmit the ID via the URL.
> 
> It WILL, though, mean that users can have separate sessions in different
> tabs in the browser, which is the effect of the original problem that
> was requested help with.

Only, if the user manually removes the session ID in the URL *and*
Cookies are not used at all.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6249

Peter H. Coffin wrote:

> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>> I have page data being sent through a php script that uses sessions to
>> pass along variables. These vars are used to load data.
>>
>> If a user opens a page, everything works fine.
>> If they open another in a new window it works fine.
>> If they tab back over to the original browser window and hit refresh it
>> switches to the last page they opened in the other window.
>>
>> This is because sessions is keeping that last var data in memory so the
>> old page when refreshed reads the new var data and opens new data
>> instead of refreshing the old.
>>
>> How would I go about fixing this so a page doesn't lose it's var data on
>> refresh?
> 
> Set session.use_trans_sid, unset session.use_cookie, don't forget to
> grab the session ID out of the $_GET array for every page load. Yes,
> your URLs will be ugly, and it'll be not impossible for someone to end
> up screwing things somehow with URL bookmarking or sharing.

More importantly, it will be a security hole to be exploited:

<https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Manage_Session_ID_as_Any_Other_User_Input>


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#6251

On Tue, 05 Jun 2012 06:46:28 +0200, Thomas 'PointedEars' Lahn wrote:
>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>> grab the session ID out of the $_GET array for every page load. Yes,
>> your URLs will be ugly, and it'll be not impossible for someone to end
>> up screwing things somehow with URL bookmarking or sharing.
>
> More importantly, it will be a security hole to be exploited:
>
><https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Manage_Session_ID_as_Any_Other_User_Input>

Sorry, I refuse to think of what *should be* expected behavior as a
"security hole". People can manipulate cookie values almost as easily
and they're no more trustworthy than a $_GET result. This doesn't even
bear discussing separately, and doing so only ends up further
complicating an issue that enough people have trouble learning into
their bones in the first place.

-- 
Judging by this particular thread, many people in this group spent their
school years taking illogical, pointless orders from morons and having
their will to live systematically crushed. And people say school doesn't
prepare kids for the real world. -- Rayner, in the Monastery

[toc] | [prev] | [next] | [standalone]

#6252

Peter H. Coffin wrote:

> On Tue, 05 Jun 2012 06:46:28 +0200, Thomas 'PointedEars' Lahn wrote:
>>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>>> grab the session ID out of the $_GET array for every page load. Yes,
>>> your URLs will be ugly, and it'll be not impossible for someone to end
>>> up screwing things somehow with URL bookmarking or sharing.
>>
>> More importantly, it will be a security hole to be exploited:
>>
>><https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Manage_Session_ID_as_Any_Other_User_Input>
> 
> Sorry, I refuse to think of what *should be* expected behavior

It is by no means expected behavior.

> as a "security hole". People can manipulate cookie values almost as easily

Because of that, HTTP-only cookies have been invented.

> and they're no more trustworthy than a $_GET result.

Correct, but by contrast they are not stored unencrypted in the user's 
history, cannot be accidentally transmitted, and so on.

> This doesn't even bear discussing separately, and doing so only ends up
> further complicating an issue that enough people have trouble learning
> into their bones in the first place.

You are wrong.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#6253

On Tue, 05 Jun 2012 20:52:23 +0200, Thomas 'PointedEars' Lahn wrote:
> Peter H. Coffin wrote:
>
>> On Tue, 05 Jun 2012 06:46:28 +0200, Thomas 'PointedEars' Lahn wrote:
>>>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>>>> grab the session ID out of the $_GET array for every page load. Yes,
>>>> your URLs will be ugly, and it'll be not impossible for someone to end
>>>> up screwing things somehow with URL bookmarking or sharing.
>>>
>>> More importantly, it will be a security hole to be exploited:
>>>
>>><https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Manage_Session_ID_as_Any_Other_User_Input>
>> 
>> Sorry, I refuse to think of what *should be* expected behavior
>
> It is by no means expected behavior.

Sure it is. "DO NOT TRUST THE CLIENT". Clean incoming stuff, provide for
backing out everything that the client does, etc. The same stuff we
always end up talking about as "security holes" are not discrete little
things but part of an overriding principle. Learning only the little
things and not the principle is WHY stuff becomes exploitable.

>> as a "security hole". People can manipulate cookie values almost as easily
>
> Because of that, HTTP-only cookies have been invented.

DO NOT TRUST THE CLIENT. That only *helps* mitigate third-party attacks.
It something between bupkis and squat against someone that's trying to
hijack a session and has access to anything more than a javascript jail.

>> and they're no more trustworthy than a $_GET result.
>
> Correct, but by contrast they are not stored unencrypted in the user's 
> history, cannot be accidentally transmitted, and so on.

If the site's properly policing client input, all of those things are
dealt with, from the site's perspective. From the user's perspective,
the same hazards exist with cookies, http-only or otherwise, or are
"secured" by only by preventing exactly the kind of behavior that the
OP is hoping to enable: separating the session from the one-to-one
relationship with the browser/OS-user combination to something else.

>> This doesn't even bear discussing separately, and doing so only ends up
>> further complicating an issue that enough people have trouble learning
>> into their bones in the first place.
>
> You are wrong.

Heh. Succinct, but about as useful as "You are a doody-head".

-- 
29. I will dress in bright and cheery colors, and so throw my enemies 
   into confusion.
        --Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [next] | [standalone]

#6262

Peter H. Coffin wrote:

> On Tue, 05 Jun 2012 20:52:23 +0200, Thomas 'PointedEars' Lahn wrote:
>> Peter H. Coffin wrote:
>>> On Tue, 05 Jun 2012 06:46:28 +0200, Thomas 'PointedEars' Lahn wrote:
>>>>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>>>>> grab the session ID out of the $_GET array for every page load. Yes,
>>>>> your URLs will be ugly, and it'll be not impossible for someone to end
>>>>> up screwing things somehow with URL bookmarking or sharing.
>>>>
>>>> More importantly, it will be a security hole to be exploited:
>>>>
>>>><https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Manage_Session_ID_as_Any_Other_User_Input>
>>> 
>>> Sorry, I refuse to think of what *should be* expected behavior
>>
>> It is by no means expected behavior.
> 
> Sure it is.

I am afraid that either I am misunderstanding your position or you do not 
know what you are arguing for or against.

> "DO NOT TRUST THE CLIENT".

That is beside the point.

>>> as a "security hole". People can manipulate cookie values almost as
>>> easily
>>
>> Because of that, HTTP-only cookies have been invented.
> 
> DO NOT TRUST THE CLIENT. That only *helps* mitigate third-party attacks.

DO NOT SHOUT AROUND HERE.  If you read my posting more carefully, you will 
realize that by no means I am saying that we should trust the client.  
However, different approaches result in different risk assessments.  The 
risk of transmitting a session ID accidentally is greater when it is part of 
the URI.  Therefore, it is *safer* (not: safe) to use HTTP-only cookies for 
that than a URI component.

On a side note, storing the session ID in cookies instead of URIs also is 
more search-engine friendly.  The resulting document becomes considerably 
smaller (the more links, the smaller), and no additional measures have to be 
applied that the search engine would not index those URIs.
 
>>> and they're no more trustworthy than a $_GET result.
>>
>> Correct, but by contrast they are not stored unencrypted in the user's
>> history, cannot be accidentally transmitted, and so on.
> 
> If the site's properly policing client input, all of those things are
> dealt with, from the site's perspective.

Intrinsically, they cannot be dealt with completely.

>>> This doesn't even bear discussing separately, and doing so only ends up
>>> further complicating an issue that enough people have trouble learning
>>> into their bones in the first place.
>>
>> You are wrong.
> 
> Heh. Succinct, but about as useful as "You are a doody-head".

That paragraph of yours constituted a fallacy.  There was nothing else to 
reply while staying polite and saving free-time for more important problems.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#6261

On 6/5/12 8:14 AM, Peter H. Coffin wrote:
> On Tue, 05 Jun 2012 06:46:28 +0200, Thomas 'PointedEars' Lahn wrote:
>>> Set session.use_trans_sid, unset session.use_cookie, don't forget to
>>> grab the session ID out of the $_GET array for every page load. Yes,
>>> your URLs will be ugly, and it'll be not impossible for someone to end
>>> up screwing things somehow with URL bookmarking or sharing.
>>
>> More importantly, it will be a security hole to be exploited:
>>
>> <https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Manage_Session_ID_as_Any_Other_User_Input>
> 
> Sorry, I refuse to think of what *should be* expected behavior as a
> "security hole". People can manipulate cookie values almost as easily
> and they're no more trustworthy than a $_GET result. This doesn't even
> bear discussing separately, and doing so only ends up further
> complicating an issue that enough people have trouble learning into
> their bones in the first place.
> 

The security hole is treating the SessionI D as totally safe to using in
any manner, doing things like building SQL queries by just appending the
value (without going through escaping, since real session id's don't
need to be escaped).

[toc] | [prev] | [next] | [standalone]

#6239

Le 03/06/2012 05:17, Michael Joel a écrit :
> I have page data being sent through a php script that uses sessions to
> pass along variables. These vars are used to load data.
>
> If a user opens a page, everything works fine.
> If they open another in a new window it works fine.

same browser? ==>> same session


> If they tab back over to the original browser window and hit refresh it
> switches to the last page they opened in the other window.
>
> This is because sessions is keeping that last var data in memory so the
> old page when refreshed reads the new var data and opens new data
> instead of refreshing the old.


I think the problem is every loaded pages change the state of
the server so the 2 opened windows are linked together.


>
> How would I go about fixing this so a page doesn't lose it's var data on
> refresh?
>
> Mike


since pages sharing same datas. It is not possible like this.

But is it really a problem?


Fred

[toc] | [prev] | [next] | [standalone]

#6240

Fred wrote:
> Le 03/06/2012 05:17, Michael Joel a écrit :
> 
>> I have page data being sent through a php script that uses sessions to
>> pass along variables. These vars are used to load data.
>>
>> If a user opens a page, everything works fine.
>> If they open another in a new window it works fine.
> 
> 
> same browser? ==>> same session
> 
> 
>> If they tab back over to the original browser window and hit refresh it
>> switches to the last page they opened in the other window.
>>
>> This is because sessions is keeping that last var data in memory so the
>> old page when refreshed reads the new var data and opens new data
>> instead of refreshing the old.
> 
> 
> 
> I think the problem is every loaded pages change the state of
> the server so the 2 opened windows are linked together.
> 
> 
>>
>> How would I go about fixing this so a page doesn't lose it's var data on
>> refresh?
>>
>> Mike
> 
> 
> 
> since pages sharing same datas. It is not possible like this.
> 
> But is it really a problem?
> 
> 
> Fred

It is if the user wants to open to documents at once and tries to 
refresh on.

I guess the easiest is to go with passing data by the url, not clean 
looking but the information is the important thing.

Mike

[toc] | [prev] | [next] | [standalone]

#6241

Le 03/06/2012 15:59, Michael Joel a écrit :

> It is if the user wants to open to documents at once and tries to
> refresh on.
>
> I guess the easiest is to go with passing data by the url, not clean
> looking but the information is the important thing.
>
> Mike

I see  what you mean.
It's not so bad. Many sites proceed like this with a permalink or a
kind of request. And URL could be bookmarked to access to specific
information.


Fred

[toc] | [prev] | [next] | [standalone]

#6242

On Sun, 03 Jun 2012 16:43:07 +0200, Fred wrote:

> Le 03/06/2012 15:59, Michael Joel a écrit :

>> It is if the user wants to open to documents at once and tries to
>> refresh on.

>> I guess the easiest is to go with passing data by the url, not clean
>> looking but the information is the important thing.

> I see  what you mean.
> It's not so bad. Many sites proceed like this with a permalink or a kind
> of request. And URL could be bookmarked to access to specific
> information.

Perhaps the issue here is using one web page to present too many 
different sets of content? And it might be better to either separate the 
required content by url.

If that's not possible, pass a "sub-session" (for want of a better term) 
id in the get, and track in the session which sub-session was displaying 
which set of content data. Sub-session ids would only be valid for the 
current session, and could be fairly short, as you have a 62 element 
alphabet to work with, 0-9A-Za-z, so eg 4 characters gives you 62^4 (over 
14 million) identifiers.

You'd need to add a new sub-session id whenever you generated a link to  
content that wasn't already in the session's table.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#6245

Michael Joel, 03.06.2012 05:17:

> I have page data being sent through a php script that uses sessions to
> pass along variables. These vars are used to load data.
> 
> If a user opens a page, everything works fine.
> If they open another in a new window it works fine.
> If they tab back over to the original browser window and hit refresh it
> switches to the last page they opened in the other window.
> 
> This is because sessions is keeping that last var data in memory so the
> old page when refreshed reads the new var data and opens new data
> instead of refreshing the old.

Well - thats what sessions are made for - manage a state for a *client*,
not a single *window* or tab.

> How would I go about fixing this so a page doesn't lose it's var data on
> refresh?

Think about your concept. Either you use a state within the session or
you use the URL (or URL parameters) to determine, what to display. But
the session will always be the same, even if the user opens multiple
windows/tabs within the same browser.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#6246

El 03/06/2012 5:17, Michael Joel escribió/wrote:
> I have page data being sent through a php script that uses sessions to
> pass along variables. These vars are used to load data.
>
> If a user opens a page, everything works fine.
> If they open another in a new window it works fine.
> If they tab back over to the original browser window and hit refresh it
> switches to the last page they opened in the other window.
>
> This is because sessions is keeping that last var data in memory so the
> old page when refreshed reads the new var data and opens new data
> instead of refreshing the old.
>
> How would I go about fixing this so a page doesn't lose it's var data on
> refresh?

Your description suggests that you are using a (single) global session 
variable to save a setting that can take many values. It's hard to 
suggest a fix without further details but I have the impression that you 
should be using an array to store the server side information and a GET 
parameter to store the array key. E.g.: instead of:

/example.php
$_SESSION['search'] = 'foo'
$_SESSION['page'] = 33
$_SESSION['results'] = 'blah';

... you should do something like:

/example.php?search=foo&page=33
$_SESSION['foo'][33]['results'] = 'blah';

/example.php?search=bar&page=1
$_SESSION['bar'][1]['results'] = 'hello';



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#6254

Thanks for all the information.

I decoded to just pass all variables through the URL.
There is no security threat since there is nothing needing security to 
it. They are all just documents available for public viewing. Right now 
no information (except document selection) is taken from the user.

If I get into needing user input then I will need to start worrying 
about security.

Again Thanks,
Mike

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web