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

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

Pass varible with out URL and SESSION

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

Contents

  Pass varible with out  URL and SESSION Biju S <biju@pixnnova.com> - 2012-12-22 01:18 -0800
    Re: Pass varible with out  URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 10:24 +0100
      Re: Pass varible with out  URL and SESSION Luuk <luuk@invalid.lan> - 2012-12-22 11:05 +0100
        Re: Pass varible with out  URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 11:37 +0100
          Re: Pass varible with out  URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 11:40 +0100
            Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 12:29 +0000
              Re: Pass varible with out  URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-22 12:21 -0500
                Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 22:55 +0000
                  Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 18:03 -0500
                    Re: Pass varible with out  URL and SESSION Luuk <luuk@invalid.lan> - 2012-12-23 08:56 +0100
                      Re: Pass varible with out  URL and SESSION houghi <houghi@houghi.org.invalid> - 2012-12-23 15:25 +0100
                      Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-23 11:21 -0500
                  Re: Pass varible with out  URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-23 12:27 -0500
                    Re: Pass varible with out  URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-23 18:45 +0100
    Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-22 13:15 +0000
      Re: Pass varible with out  URL and SESSION Scott Johnson <noonehome@chalupasworld.com> - 2012-12-22 05:26 -0800
        Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 14:43 +0000
          Re: Pass varible with out  URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-22 12:23 -0500
            Re: Pass varible with out  URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-22 21:55 +0100
              Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-22 22:56 +0000
                Re: Pass varible with out  URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-23 18:02 +0100
            Re: Pass varible with out  URL and SESSION Gregor Kofler <usenet@gregorkofler.com> - 2012-12-23 00:43 +0100
              Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-23 00:09 +0000
                Re: Pass varible with out  URL and SESSION "Andy" <andy@NOSPAMmanyplay.com> - 2012-12-24 09:30 +0000
                  Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 08:30 -0500
                    Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-24 16:40 +0000
                      Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 13:56 -0500
                        Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-24 22:26 +0000
                          Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-24 23:30 +0000
                          Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 20:23 -0500
                            Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-25 12:21 +0000
                              Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 08:41 -0500
                              Re: Pass varible with out  URL and SESSION "Peter H. Coffin" <hellsop@ninehells.com> - 2012-12-25 10:14 -0600
                                Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-25 19:25 +0000
                                Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-26 01:21 +0000
                                  Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 20:36 -0500
                                    Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-26 02:21 +0000
                                      Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 21:47 -0500
                          Re: Pass varible with out  URL and SESSION "Andy" <andy@NOSPAMmanyplay.com> - 2012-12-25 10:03 +0000
                            Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-25 10:31 +0000
                            Re: Pass varible with out  URL and SESSION "J.O. Aho" <user@example.net> - 2012-12-25 13:10 +0100
                              Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-25 13:23 +0000
                                Re: Pass varible with out  URL and SESSION "J.O. Aho" <user@example.net> - 2012-12-25 16:08 +0100
                              Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 08:44 -0500
                              Re: Pass varible with out  URL and SESSION "Andy" <andy@NOSPAMmanyplay.com> - 2012-12-27 09:22 +0000
                            Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 08:42 -0500
                  Re: Pass varible with out  URL and SESSION adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2012-12-24 13:41 +0000
                    Re: Pass varible with out  URL and SESSION Scott Johnson <noonehome@chalupasworld.com> - 2012-12-24 06:23 -0800
                      Re: Pass varible with out  URL and SESSION adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2012-12-24 15:43 +0000
                        Re: Pass varible with out  URL and SESSION "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-12-24 17:07 +0100
                        Re: Pass varible with out  URL and SESSION "J.O. Aho" <user@example.net> - 2012-12-24 22:36 +0100
                          Re: Pass varible with out  URL and SESSION The Natural Philosopher <tnp@invalid.invalid> - 2012-12-24 23:25 +0000
                            Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-24 20:25 -0500
              Re: Pass varible with out  URL and SESSION "Twayne" <nobody@devnull.spamcop.net> - 2012-12-23 12:37 -0500
                Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-23 13:36 -0500
      Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 09:32 -0500
        Re: Pass varible with out  URL and SESSION Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-22 18:09 +0000
          Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 13:45 -0500
    Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-22 08:25 -0500
    Re: Pass varible with out  URL and SESSION Gregor Kofler <usenet@gregorkofler.com> - 2012-12-22 17:35 +0100
    Re: Pass varible with out  URL and SESSION email.nandkishore@gmail.com - 2012-12-22 09:51 -0800
    Re: Pass varible with out  URL and SESSION Biju S <biju@pixnnova.com> - 2012-12-25 07:20 -0800
      Re: Pass varible with out  URL and SESSION Jerry Stuckle <jstucklex@attglobal.net> - 2012-12-25 11:40 -0500

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#7924

On 25/12/12 11:03, Andy wrote:

> In fact, I too use this frame method in an ecommerce site so that if the
> customer browses back to the shopping cart after filling in some/all
> details on the checkout page, the information is restored when they
> decide to proceed to the checkout.

Works as long as someone don't go directly the the page, then there is 
no frame to store the data to. I would call this a quite unstable 
solution which depends on quite many assumptions about the user.


-- 

  //Aho

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

#7926

On Tue, 25 Dec 2012 13:10:33 +0100, J.O. Aho wrote:

> On 25/12/12 11:03, Andy wrote:
> 
>> In fact, I too use this frame method in an ecommerce site so that if
>> the customer browses back to the shopping cart after filling in
>> some/all details on the checkout page, the information is restored when
>> they decide to proceed to the checkout.
> 
> Works as long as someone don't go directly the the page, then there is
> no frame to store the data to. I would call this a quite unstable
> solution which depends on quite many assumptions about the user.

You test for the expected parent frame in the javascript, and if it's not 
there, load it by with window.location.replace("<parent_frame_url>");

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#7930

On 25/12/12 14:23, Denis McMahon wrote:
> On Tue, 25 Dec 2012 13:10:33 +0100, J.O. Aho wrote:
>
>> On 25/12/12 11:03, Andy wrote:
>>
>>> In fact, I too use this frame method in an ecommerce site so that if
>>> the customer browses back to the shopping cart after filling in
>>> some/all details on the checkout page, the information is restored when
>>> they decide to proceed to the checkout.
>>
>> Works as long as someone don't go directly the the page, then there is
>> no frame to store the data to. I would call this a quite unstable
>> solution which depends on quite many assumptions about the user.
>
> You test for the expected parent frame in the javascript, and if it's not
> there, load it by with window.location.replace("<parent_frame_url>");

And you lost the connection with things they may have been doing already 
in another frame setup in another window/tab.

-- 

  //Aho

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

#7929

On 12/25/2012 7:10 AM, J.O. Aho wrote:
> On 25/12/12 11:03, Andy wrote:
>
>> In fact, I too use this frame method in an ecommerce site so that if the
>> customer browses back to the shopping cart after filling in some/all
>> details on the checkout page, the information is restored when they
>> decide to proceed to the checkout.
>
> Works as long as someone don't go directly the the page, then there is
> no frame to store the data to. I would call this a quite unstable
> solution which depends on quite many assumptions about the user.
>
>

It is, J.O.  Overly complicated and full of all kinds of potential 
problems.  Plus it has nothing to do with PHP, and is off topic here.

Some people just can't understand simple concepts like newsgroup topics. 
  They also are so entranced with their "solution" they can't see the 
problems it can cause.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#7956

"J.O. Aho" <user@example.net> wrote in message 
news:ajtjdpF4rinU1@mid.individual.net...
> On 25/12/12 11:03, Andy wrote:
>
>> In fact, I too use this frame method in an ecommerce site so that if the
>> customer browses back to the shopping cart after filling in some/all
>> details on the checkout page, the information is restored when they
>> decide to proceed to the checkout.
>
> Works as long as someone don't go directly the the page, then there is no 
> frame to store the data to. I would call this a quite unstable solution 
> which depends on quite many assumptions about the user.
>
>
> -- 
>
>  //Aho
>
>

Incorrect, the link I gave as an example was a direct link. I just use a bit 
of javascript to reconstruct the frameset. In fact, that page uses 13 
frames!

Andy 

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

#7928

On 12/25/2012 5:03 AM, Andy wrote:
>
>
> "Denis McMahon" <denismfmcmahon@gmail.com> wrote in message
> news:kbakra$lmv$1@dont-email.me...
>> On Mon, 24 Dec 2012 13:56:17 -0500, Jerry Stuckle wrote:
>>
>>> On 12/24/2012 11:40 AM, Denis McMahon wrote:
>>>> On Mon, 24 Dec 2012 08:30:45 -0500, Jerry Stuckle wrote:
>>>>
>>>>> On 12/24/2012 4:30 AM, Andy wrote:
>>>>>>> well exactly. There are only three ways to keep track of a browser
>>>>>>> state between pages: cookie, GET or POST.
>>>>>>
>>>>>> In the words of Yoda "There is another"...
>>>>>>
>>>>>> You guys won't like it but I thought it worth mentioning that you can
>>>>>> also use a hidden frame and store any variable to be passed back to
>>>>>> the next content page.
>>>>
>>>>> Which still comes back in the GET or POST values, as applicable.
>>>>
>>>> I think Andy is suggesting a client side method that uses javascript to
>>>> store a variable in a higher level frame between page loads. This could
>>>> be used to pass data between the javascript code running in two pages
>>>> on a client without passing the data through the server.
>>>>
>>>> It's a similar approach to using js to create a cookie on the client
>>>> side that can be read by js in another page on the client side, to pass
>>>> data between pages on the client side without relying on the server.
>>>>
>>>> However, as we already agreed (I think), until we have more information
>>>> about what the OP actually wants to do, and specifically whether he's
>>>> trying to pass state information between pages on the client or on the
>>>> server, it's a bit pointless debating the ins and outs of the various
>>>> possible methods.
>>
>>> But it's still passed back to the server via POST or GET.  All he's
>>> suggesting is a different way of storing it on the client (i.e. instead
>>> of a hidden field in a form).
>>
>> No, he's suggesting a way to pass data from a client side script running
>> in one page on the client to a client page script running in another page
>> on the client *without* going back through the server at all.
>>
>> Scenario:
>>
>> A frameset has javascript methods set( param, value ) and get(param)
>>
>> Any pages loaded into a subframe of that frameset, from the same host
>> (xss
>> restrictions will apply if the page is from a different host) can call
>> the set and get methods in the parent frameset to store / retrieve values
>> that will never be passed through the server.
>>
>> I once wrote a shopping catalogue that ran 100% in client side javascript
>> doing this, for someone who was running on a hosting provider that only
>> made a basic mailform cgi available. Customers could browse the
>> catalogue, pick out their goods, and then mail their shopping list to the
>> company using the mailform cgi.
>>
>> The (mom & pop) company would then contact the customer, confirm the
>> requirement, put it on their van and deliver it, collecting payment when
>> they delivered.
>>
>> The only time that any "data" apart from plain page requests got sent to
>> the server was after the complete order had been assembled, when it was
>> sent to the mailform cgi on the server, and that could have been avoided
>> by generating a mail uri that would have launched the default mail
>> application on the client computer and populate the message text.
>>
>> The same can be done with a javascript cookie, although the cookie in
>> that case does get sent to the server the server just discards it, but
>> the javascript in different pages from the same host (again security
>> constraints apply) on the client can read and write the cookie and use it
>> to pass data values between themselves.
>>
>> --
>> Denis McMahon, denismfmcmahon@gmail.com
>
> Hi,
>
> Dennis is correct.
>
> In fact, I too use this frame method in an ecommerce site so that if the
> customer browses back to the shopping cart after filling in some/all
> details on the checkout page, the information is restored when they
> decide to proceed to the checkout.
>
> No data is sent to the server other than fetching the checkout page and
> no data is stored on the client's computer. The information is stored in
> the 'header' frame as javascript variables and recalled by the checkout
> page loaded into the 'content' frame...
>
> onBlur="parent.HEADING.mydetails_firstname=mydetails_firstname.value;
>
> if (parent.HEADING.mydetails_firstname!=''){
> document.getElementById('mydetails_firstname').value=parent.HEADING.mydetails_firstname;
>
> }
>
> If you want to see it in action, visit the following link which will
> land on the shopping cart page with a product (a PC) already added to
> your order...
>
> https://www.microbuild.com/microbuild/catalog/shopping_cart.php?action=buy_now&products_id=181
>
>
> ... Then click the 'Place Order' button to take you to the checkout page
> and fill in any test information you like. Click the 'Back to My Order'
> button to return to the shopping cart and then click the 'Place Order'
> button again to return to the checkout page. You'll see that any
> information you entered previously has been magically preserved :)
>
> Andy
>
> Ps Merry Christmas everyone.

So?  PHP doesn't run on the client.  The fact he's asking here means he 
wants something which can be handled by PHP.

So take your javascript crap someplace else.  It has no business here.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#7910

Andy <andy@NOSPAMmanyplay.com> wrote:

> > well exactly. There are only three ways to keep track of a browser state
> > between pages: cookie, GET or POST.
> 
> In the words of Yoda "There is another"...
> 
> You guys won't like it but I thought it worth mentioning that you can also
> use a hidden frame and store any variable to be passed back to the next
> content page.

As a complete beginner, I would be grateful if you could elaborate on
that.


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#7911

On 12/24/2012 5:41 AM, Adrian Tuddenham wrote:
> Andy <andy@NOSPAMmanyplay.com> wrote:
>
>>> well exactly. There are only three ways to keep track of a browser state
>>> between pages: cookie, GET or POST.
>>
>> In the words of Yoda "There is another"...
>>
>> You guys won't like it but I thought it worth mentioning that you can also
>> use a hidden frame and store any variable to be passed back to the next
>> content page.
>
> As a complete beginner, I would be grateful if you could elaborate on
> that.
>
>

As Jerry mentioned, you still have to use one of the 3 methods.  POST, 
GET, COOKIE.

If you use a frame, invisible or not, once you resend the header to load 
another page, from the root page or frame (does not matter), you still 
have to send variables as mentioned above.

Still wondering why the OP does has these restrictions or is just 
curious if it can be done or if he has flown the coop.

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

#7912

Scott Johnson <noonehome@chalupasworld.com> wrote:

> On 12/24/2012 5:41 AM, Adrian Tuddenham wrote:
> > Andy <andy@NOSPAMmanyplay.com> wrote:
> >
> >>> well exactly. There are only three ways to keep track of a browser state
> >>> between pages: cookie, GET or POST.
> >>
> >> In the words of Yoda "There is another"...
> >>
> >> You guys won't like it but I thought it worth mentioning that you can also
> >> use a hidden frame and store any variable to be passed back to the next
> >> content page.
> >
> > As a complete beginner, I would be grateful if you could elaborate on
> > that.
> >
> >
> 
> As Jerry mentioned, you still have to use one of the 3 methods.  POST,
> GET, COOKIE.
> 
> If you use a frame, invisible or not, once you resend the header to load
> another page, from the root page or frame (does not matter), you still
> have to send variables as mentioned above.

Presumably there is nothing to stop you writing the variable to a file
and then reading it back on the next page?  

The only problem, with a busy website, would be identifying whether the
same user is requesting that variable as the one who wrote it.  Could
that be taken care of by storing an array in the file and associating
each variable with each user's IP number?  As long as the IP number
didn't change during a session, this would select the wanted variable
for that user.


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#7913

Am 24.12.2012 16:43, schrieb Adrian Tuddenham:
> Scott Johnson <noonehome@chalupasworld.com> wrote:
> 
>> On 12/24/2012 5:41 AM, Adrian Tuddenham wrote:
>>> Andy <andy@NOSPAMmanyplay.com> wrote:
>>>
>>>>> well exactly. There are only three ways to keep track of a browser state
>>>>> between pages: cookie, GET or POST.
>>>>
>>>> In the words of Yoda "There is another"...
>>>>
>>>> You guys won't like it but I thought it worth mentioning that you can also
>>>> use a hidden frame and store any variable to be passed back to the next
>>>> content page.
>>>
>>> As a complete beginner, I would be grateful if you could elaborate on
>>> that.
>>>
>>>
>>
>> As Jerry mentioned, you still have to use one of the 3 methods.  POST,
>> GET, COOKIE.
>>
>> If you use a frame, invisible or not, once you resend the header to load
>> another page, from the root page or frame (does not matter), you still
>> have to send variables as mentioned above.
> 
> Presumably there is nothing to stop you writing the variable to a file
> and then reading it back on the next page?  
> 
> The only problem, with a busy website, would be identifying whether the
> same user is requesting that variable as the one who wrote it.  Could
> that be taken care of by storing an array in the file and associating
> each variable with each user's IP number?  As long as the IP number
> didn't change during a session, this would select the wanted variable
> for that user.

It all boils down to the problem to identify the client who entered the correct
credentials.

If you propose to use the IP, take a look at what a proxy server does, and what NAT does.

If you propose (sender IP:sender port), you would have a unique endpoint. But this is
lost as soon as the client opens a new TCP connection, what happens quite often.

/Str.

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

#7916

On 24/12/12 16:43, Adrian Tuddenham wrote:
> Scott Johnson <noonehome@chalupasworld.com> wrote:

>> As Jerry mentioned, you still have to use one of the 3 methods.  POST,
>> GET, COOKIE.
>>
>> If you use a frame, invisible or not, once you resend the header to load
>> another page, from the root page or frame (does not matter), you still
>> have to send variables as mentioned above.
>
> Presumably there is nothing to stop you writing the variable to a file
> and then reading it back on the next page?

If you want to store the data, you need to send it to the server with 
help of GET/POST/PUT, Andy was suggesting that he could store values 
without sending the data to the server, this could be done in a way with 
javascript, but the server wouldn't be able to act on the data and you 
need to make it somewhat crafty design which is easily broken by the user.


> The only problem, with a busy website, would be identifying whether the
> same user is requesting that variable as the one who wrote it.

This is why you use sessions, the session cookie can of course be 
hijacked, but it will keep track of who is associated with what data.


> Could
> that be taken care of by storing an array in the file and associating
> each variable with each user's IP number?  As long as the IP number
> didn't change during a session, this would select the wanted variable
> for that user.

You could do that, but you would get issues when you have more than one 
user from the same ip or a user who change ip during the visit at the 
site. I would say the solution is a big step backwards compared to sessions.

-- 

  //Aho

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

#7918

On 24/12/12 21:36, J.O. Aho wrote:
> On 24/12/12 16:43, Adrian Tuddenham wrote:
>> Scott Johnson <noonehome@chalupasworld.com> wrote:
>
>>> As Jerry mentioned, you still have to use one of the 3 methods.  POST,
>>> GET, COOKIE.
>>>
>>> If you use a frame, invisible or not, once you resend the header to load
>>> another page, from the root page or frame (does not matter), you still
>>> have to send variables as mentioned above.
>>
>> Presumably there is nothing to stop you writing the variable to a file
>> and then reading it back on the next page?
>
> If you want to store the data, you need to send it to the server with
> help of GET/POST/PUT, Andy was suggesting that he could store values
> without sending the data to the server, this could be done in a way with
> javascript, but the server wouldn't be able to act on the data and you
> need to make it somewhat crafty design which is easily broken by the user.
>
>
>> The only problem, with a busy website, would be identifying whether the
>> same user is requesting that variable as the one who wrote it.
>
> This is why you use sessions, the session cookie can of course be
> hijacked, but it will keep track of who is associated with what data.
>
>
>> Could
>> that be taken care of by storing an array in the file and associating
>> each variable with each user's IP number?  As long as the IP number
>> didn't change during a session, this would select the wanted variable
>> for that user.
>
> You could do that, but you would get issues when you have more than one
> user from the same ip or a user who change ip during the visit at the
> site. I would say the solution is a big step backwards compared to
> sessions.
>
well cookies, anyway. I didn't find sessions gave me anything using was 
cookies didn't.

The POST method is good but wont survive a browser shutdown. Most 
browsers store cookies on the local hard drive.




-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

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

#7921

On 12/24/2012 6:25 PM, The Natural Philosopher wrote:
> On 24/12/12 21:36, J.O. Aho wrote:
>> On 24/12/12 16:43, Adrian Tuddenham wrote:
>>> Scott Johnson <noonehome@chalupasworld.com> wrote:
>>
>>>> As Jerry mentioned, you still have to use one of the 3 methods.  POST,
>>>> GET, COOKIE.
>>>>
>>>> If you use a frame, invisible or not, once you resend the header to
>>>> load
>>>> another page, from the root page or frame (does not matter), you still
>>>> have to send variables as mentioned above.
>>>
>>> Presumably there is nothing to stop you writing the variable to a file
>>> and then reading it back on the next page?
>>
>> If you want to store the data, you need to send it to the server with
>> help of GET/POST/PUT, Andy was suggesting that he could store values
>> without sending the data to the server, this could be done in a way with
>> javascript, but the server wouldn't be able to act on the data and you
>> need to make it somewhat crafty design which is easily broken by the
>> user.
>>
>>
>>> The only problem, with a busy website, would be identifying whether the
>>> same user is requesting that variable as the one who wrote it.
>>
>> This is why you use sessions, the session cookie can of course be
>> hijacked, but it will keep track of who is associated with what data.
>>
>>
>>> Could
>>> that be taken care of by storing an array in the file and associating
>>> each variable with each user's IP number?  As long as the IP number
>>> didn't change during a session, this would select the wanted variable
>>> for that user.
>>
>> You could do that, but you would get issues when you have more than one
>> user from the same ip or a user who change ip during the visit at the
>> site. I would say the solution is a big step backwards compared to
>> sessions.
>>
> well cookies, anyway. I didn't find sessions gave me anything using was
> cookies didn't.
>
> The POST method is good but wont survive a browser shutdown. Most
> browsers store cookies on the local hard drive.
>
>
>
>

It gives you SECURITY as the data is not sent to the client - only the 
session id is.  But then noobs don't know (or care) about security.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#7905

In news:kb5gi4$4fe$1@dont-email.me,
Gregor Kofler <usenet@gregorkofler.com> typed:
> Am 2012-12-22 18:23, Twayne meinte:
>> In news:kb4guc$dng$2@news.albasani.net,
>> The Natural Philosopher <tnp@invalid.invalid> typed:
>>> On 22/12/12 13:26, Scott Johnson wrote:
>>>> On 12/22/2012 5:15 AM, Denis McMahon wrote:
>>>>> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote:
>>>>>
>>>>>> Pass varible to One page to other page ....
>>>>>> With out Url varible and session ....
>>>>>> any way
>>>>>
>>>>> Put it in a cookie that gets saved on the client. Use
>>>>> javascript to manipulate the cookie to store /
>>>>> retrieve the value. Ask in a javascript group or
>>>>> forum for more details. Won't work if the client
>>>>> routinely disables javascript from untrusted servers.
>>>>
>>>> Or POST I suppose
>>>>
>>> well, POST is all there is, since session stuff IS
>>> cookies, just in a pretty dress.
>>>
>>>
>>>> Scotty
>>
>> Not quite: Sessions do not put anything on the client
>> side machine. It's all kept on the server if it's wrtten
>> properly. They definitely are NOT cookies; please have a
>> look at the manual.
>
> They *frequently* do. Unless one doesn't want to transfer
> the session id as URL parameter, it is stored in a
> session cookie which contains the session id, which the
> server then can use to access the server-side stored
> actual data.
> Since you advise others to read the manual - have a look
> at:
> http://php.net/manual/en/session.idpassing.php
>
> " There are two methods to propagate a session id:
>
>     Cookies
>     URL parameter
> "
>
> Gregor


Hmm, that's interesting and I stand corrected; especially from that 
respected source.  I'll have to check that out more closely.  Somehow I 
though Sessions were kept from the client side, thus my prevous answer.

Thanks, and

HTH,

Twayne`

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

#7907

On 12/23/2012 12:37 PM, Twayne wrote:
> In news:kb5gi4$4fe$1@dont-email.me,
> Gregor Kofler <usenet@gregorkofler.com> typed:
>> Am 2012-12-22 18:23, Twayne meinte:
>>> In news:kb4guc$dng$2@news.albasani.net,
>>> The Natural Philosopher <tnp@invalid.invalid> typed:
>>>> On 22/12/12 13:26, Scott Johnson wrote:
>>>>> On 12/22/2012 5:15 AM, Denis McMahon wrote:
>>>>>> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote:
>>>>>>
>>>>>>> Pass varible to One page to other page ....
>>>>>>> With out Url varible and session ....
>>>>>>> any way
>>>>>>
>>>>>> Put it in a cookie that gets saved on the client. Use
>>>>>> javascript to manipulate the cookie to store /
>>>>>> retrieve the value. Ask in a javascript group or
>>>>>> forum for more details. Won't work if the client
>>>>>> routinely disables javascript from untrusted servers.
>>>>>
>>>>> Or POST I suppose
>>>>>
>>>> well, POST is all there is, since session stuff IS
>>>> cookies, just in a pretty dress.
>>>>
>>>>
>>>>> Scotty
>>>
>>> Not quite: Sessions do not put anything on the client
>>> side machine. It's all kept on the server if it's wrtten
>>> properly. They definitely are NOT cookies; please have a
>>> look at the manual.
>>
>> They *frequently* do. Unless one doesn't want to transfer
>> the session id as URL parameter, it is stored in a
>> session cookie which contains the session id, which the
>> server then can use to access the server-side stored
>> actual data.
>> Since you advise others to read the manual - have a look
>> at:
>> http://php.net/manual/en/session.idpassing.php
>>
>> " There are two methods to propagate a session id:
>>
>>      Cookies
>>      URL parameter
>> "
>>
>> Gregor
>
>
> Hmm, that's interesting and I stand corrected; especially from that
> respected source.  I'll have to check that out more closely.  Somehow I
> though Sessions were kept from the client side, thus my prevous answer.
>
> Thanks, and
>
> HTH,
>
> Twayne`
>
>

Session DATA is held on the server. But the session ID has to come from 
the client.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#7885

On 12/22/2012 8:15 AM, Denis McMahon wrote:
> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote:
>
>> Pass varible to One page to other page ....
>> With out Url varible and session ....
>> any way
>
> Put it in a cookie that gets saved on the client. Use javascript to
> manipulate the cookie to store / retrieve the value. Ask in a javascript
> group or forum for more details. Won't work if the client routinely
> disables javascript from untrusted servers.
>

You don't need javascript to use cookies.  PHP does it quite well by itself.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#7891

On Sat, 22 Dec 2012 09:32:16 -0500, Jerry Stuckle wrote:

> On 12/22/2012 8:15 AM, Denis McMahon wrote:
>> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote:
>>
>>> Pass varible to One page to other page ....
>>> With out Url varible and session ....
>>> any way
>>
>> Put it in a cookie that gets saved on the client. Use javascript to
>> manipulate the cookie to store / retrieve the value. Ask in a
>> javascript group or forum for more details. Won't work if the client
>> routinely disables javascript from untrusted servers.
>>
>>
> You don't need javascript to use cookies.  PHP does it quite well by
> itself.

Guess it depends where he wants the variable.

I was assuming he wanted the variable in a script on the client, and that 
was why he was trying to pass it from page to page without using server 
side code. I may have been over-thinking things. :)

i.e I'm reading his request as looking for a method of maintaining some 
sort of state information on the client side when using e.g. free hosting 
that doesn't allow for any sort of server side scripting.

Perhaps the OP could give us a little more detail about what he actually 
wants to do.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#7892

On 12/22/2012 1:09 PM, Denis McMahon wrote:
> On Sat, 22 Dec 2012 09:32:16 -0500, Jerry Stuckle wrote:
>
>> On 12/22/2012 8:15 AM, Denis McMahon wrote:
>>> On Sat, 22 Dec 2012 01:18:53 -0800, Biju S wrote:
>>>
>>>> Pass varible to One page to other page ....
>>>> With out Url varible and session ....
>>>> any way
>>>
>>> Put it in a cookie that gets saved on the client. Use javascript to
>>> manipulate the cookie to store / retrieve the value. Ask in a
>>> javascript group or forum for more details. Won't work if the client
>>> routinely disables javascript from untrusted servers.
>>>
>>>
>> You don't need javascript to use cookies.  PHP does it quite well by
>> itself.
>
> Guess it depends where he wants the variable.
>
> I was assuming he wanted the variable in a script on the client, and that
> was why he was trying to pass it from page to page without using server
> side code. I may have been over-thinking things. :)
>
> i.e I'm reading his request as looking for a method of maintaining some
> sort of state information on the client side when using e.g. free hosting
> that doesn't allow for any sort of server side scripting.
>
> Perhaps the OP could give us a little more detail about what he actually
> wants to do.
>

Even if he uses javascript, he needs to pass the value back either in 
the cookie, the URL or a POST value - any of which can be done without 
javascript.

I agree we need more detail about what he's trying to do (and what he 
has against using the $_SESSION array).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#7883

On 12/22/2012 4:18 AM, Biju S wrote:
> Pass varible to One page to other page ....
> With out Url varible and session ....
> any way
>

Why don't you want to use the $_SESSION array?  That's what it's there for.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#7887

Am 2012-12-22 10:18, Biju S meinte:
> Pass varible to One page to other page ....
> With out Url varible and session ....
> any way

Url means GET, session means cookie. You could use POST.

Gregor

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web