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

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

2D array by POST

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

Contents

  2D array by POST liz@poppyrecords.invalid.invalid (Liz Tuddenham) - 2023-05-18 17:04 +0100
    Re: 2D array by POST "J.O. Aho" <user@example.net> - 2023-05-18 19:00 +0200
      Re: 2D array by POST liz@poppyrecords.invalid.invalid (Liz Tuddenham) - 2023-05-18 21:17 +0100
      Re: 2D array by POST doctor@doctor.nl2k.ab.ca (The Doctor) - 2023-05-18 21:38 +0000
        Re: 2D array by POST "J.O. Aho" <user@example.net> - 2023-05-18 23:44 +0200
          Re: 2D array by POST liz@poppyrecords.invalid.invalid (Liz Tuddenham) - 2023-05-19 07:19 +0100
            Re: 2D array by POST Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-05-19 11:56 -0400
              Re: 2D array by POST "J.O. Aho" <user@example.net> - 2023-05-19 20:27 +0200
                Re: 2D array by POST "J.O. Aho" <user@example.net> - 2023-05-19 20:29 +0200
                  Re: 2D array by POST Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-05-19 23:55 -0400
                Re: 2D array by POST liz@poppyrecords.invalid.invalid (Liz Tuddenham) - 2023-05-19 20:38 +0100
                  Re: 2D array by POST "J.O. Aho" <user@example.net> - 2023-05-19 23:58 +0200
                    Re: 2D array by POST Arne Vajhøj <arne@vajhoej.dk> - 2023-05-19 21:42 -0400
                      Re: 2D array by POST liz@poppyrecords.invalid.invalid (Liz Tuddenham) - 2023-05-20 08:56 +0100
                        Re: 2D array by POST Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-05-20 08:53 +0000
                Re: 2D array by POST Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-05-19 23:54 -0400
          Re: 2D array by POST Arne Vajhøj <arne@vajhoej.dk> - 2023-05-19 21:30 -0400
            Re: 2D array by POST Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-05-20 00:06 -0400

#19461 — 2D array by POST

I need to send a 2-dimensional array from one file to another by POST.
The array is $item[][] with contents that are entirelyintegers.

I have tried :
 Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>"; 
with
$item = stripslashes($_POST['item']);
but it does not work. 

 Any suggestions?

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

[toc] | [next] | [standalone]

#19462

On 5/18/23 18:04, Liz Tuddenham wrote:
> I need to send a 2-dimensional array from one file to another by POST.
> The array is $item[][] with contents that are entirelyintegers.
> 
> I have tried :
>   Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
> with
> $item = stripslashes($_POST['item']);
> but it does not work.
> 
>   Any suggestions?

1. use session, store the value in the session and then use it in the 
next page directly from the session.

2. serialize the variable and base64 encode the serialized data, post 
this in the form and then base64 decode and unserialize.

-- 
   //Aho

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

#19463

J.O. Aho <user@example.net> wrote:

> On 5/18/23 18:04, Liz Tuddenham wrote:
> > I need to send a 2-dimensional array from one file to another by POST.
> > The array is $item[][] with contents that are entirelyintegers.
> > 
> > I have tried :
> >   Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
> > with
> > $item = stripslashes($_POST['item']);
> > but it does not work.
> > 
> >   Any suggestions?
> 
> 1. use session, store the value in the session and then use it in the
> next page directly from the session.
> 
> 2. serialize the variable and base64 encode the serialized data, post
> this in the form and then base64 decode and unserialize.

Thanks, I'll try those suggestios.

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

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

#19464

In article <kcn3tdFehn1U1@mid.individual.net>,
J.O. Aho <user@example.net> wrote:
>On 5/18/23 18:04, Liz Tuddenham wrote:
>> I need to send a 2-dimensional array from one file to another by POST.
>> The array is $item[][] with contents that are entirelyintegers.
>> 
>> I have tried :
>>   Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>> with
>> $item = stripslashes($_POST['item']);
>> but it does not work.
>> 
>>   Any suggestions?
>
>1. use session, store the value in the session and then use it in the 
>next page directly from the session.
>
>2. serialize the variable and base64 encode the serialized data, post 
>this in the form and then base64 decode and unserialize.
>

Is base64 strong enugh?

>-- 
>   //Aho
>
>


-- 
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b 
Alberta 29 May 2023 boot out the UCP and the NDP!  Beware https://mindspring.com

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

#19465

On 5/18/23 23:38, The Doctor wrote:
> In article <kcn3tdFehn1U1@mid.individual.net>,
> J.O. Aho <user@example.net> wrote:
>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>> I need to send a 2-dimensional array from one file to another by POST.
>>> The array is $item[][] with contents that are entirelyintegers.
>>>
>>> I have tried :
>>>    Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>> with
>>> $item = stripslashes($_POST['item']);
>>> but it does not work.
>>>
>>>    Any suggestions?
>>
>> 1. use session, store the value in the session and then use it in the
>> next page directly from the session.
>>
>> 2. serialize the variable and base64 encode the serialized data, post
>> this in the form and then base64 decode and unserialize.
>>
> 
> Is base64 strong enugh?

It's not about the encryption, it's about not making the html to break 
as you don't know what the serialized data may contain.

if the data is sensitive or you want to avoid user manipulation of the 
data, then store the data in session and that is way it was number 1 of 
the suggestions.

-- 
  //Aho

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

#19466

J.O. Aho <user@example.net> wrote:

> On 5/18/23 23:38, The Doctor wrote:
> > In article <kcn3tdFehn1U1@mid.individual.net>,
> > J.O. Aho <user@example.net> wrote:
> >> On 5/18/23 18:04, Liz Tuddenham wrote:
> >>> I need to send a 2-dimensional array from one file to another by POST.
> >>> The array is $item[][] with contents that are entirelyintegers.
> >>>
> >>> I have tried :
> >>>    Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
> >>> with
> >>> $item = stripslashes($_POST['item']);
> >>> but it does not work.
> >>>
> >>>    Any suggestions?
> >>
> >> 1. use session, store the value in the session and then use it in the
> >> next page directly from the session.
> >>
> >> 2. serialize the variable and base64 encode the serialized data, post
> >> this in the form and then base64 decode and unserialize.
> >>
> > 
> > Is base64 strong enugh?
> 
> It's not about the encryption, it's about not making the html to break
> as you don't know what the serialized data may contain.
> 
> if the data is sensitive or you want to avoid user manipulation of the
> data, then store the data in session and that is way it was number 1 of
> the suggestions.

The data isn't particularly sensitive, it is just a 'shopping list'
passed from one part of a shopping program to another.  It could have
been sent as dozens of individual variables, but that seemed clumsy as
they were already nicely wrapped up in an array.


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

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

#19467

On 5/19/2023 2:19 AM, Liz Tuddenham wrote:
> J.O. Aho <user@example.net> wrote:
> 
>> On 5/18/23 23:38, The Doctor wrote:
>>> In article <kcn3tdFehn1U1@mid.individual.net>,
>>> J.O. Aho <user@example.net> wrote:
>>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>>> I need to send a 2-dimensional array from one file to another by POST.
>>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>>
>>>>> I have tried :
>>>>>     Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>>> with
>>>>> $item = stripslashes($_POST['item']);
>>>>> but it does not work.
>>>>>
>>>>>     Any suggestions?
>>>>
>>>> 1. use session, store the value in the session and then use it in the
>>>> next page directly from the session.
>>>>
>>>> 2. serialize the variable and base64 encode the serialized data, post
>>>> this in the form and then base64 decode and unserialize.
>>>>
>>>
>>> Is base64 strong enugh?
>>
>> It's not about the encryption, it's about not making the html to break
>> as you don't know what the serialized data may contain.
>>
>> if the data is sensitive or you want to avoid user manipulation of the
>> data, then store the data in session and that is way it was number 1 of
>> the suggestions.
> 
> The data isn't particularly sensitive, it is just a 'shopping list'
> passed from one part of a shopping program to another.  It could have
> been sent as dozens of individual variables, but that seemed clumsy as
> they were already nicely wrapped up in an array.
> 
> 

J.O. has the right idea.  The way to do this is to store the data in the 
$_SESSION variable to pass it on to the next page.

This is especially true if it has things like prices - which the user 
can change if you give them access to it via a web page.

-- 
==================
Remove the "x"'s from my email address
Jerry Stuckle
stucklex.jerryx@gmail.com
==================

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

#19468

On 5/19/23 17:56, Jerry Stuckle wrote:
> On 5/19/2023 2:19 AM, Liz Tuddenham wrote:
>> J.O. Aho <user@example.net> wrote:
>>
>>> On 5/18/23 23:38, The Doctor wrote:
>>>> In article <kcn3tdFehn1U1@mid.individual.net>,
>>>> J.O. Aho <user@example.net> wrote:
>>>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>>>> I need to send a 2-dimensional array from one file to another by 
>>>>>> POST.
>>>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>>>
>>>>>> I have tried :
>>>>>>     Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>>>> with
>>>>>> $item = stripslashes($_POST['item']);
>>>>>> but it does not work.
>>>>>>
>>>>>>     Any suggestions?
>>>>>
>>>>> 1. use session, store the value in the session and then use it in the
>>>>> next page directly from the session.
>>>>>
>>>>> 2. serialize the variable and base64 encode the serialized data, post
>>>>> this in the form and then base64 decode and unserialize.
>>>>>
>>>>
>>>> Is base64 strong enugh?
>>>
>>> It's not about the encryption, it's about not making the html to break
>>> as you don't know what the serialized data may contain.
>>>
>>> if the data is sensitive or you want to avoid user manipulation of the
>>> data, then store the data in session and that is way it was number 1 of
>>> the suggestions.
>>
>> The data isn't particularly sensitive, it is just a 'shopping list'
>> passed from one part of a shopping program to another.  It could have
>> been sent as dozens of individual variables, but that seemed clumsy as
>> they were already nicely wrapped up in an array.
>>
>>
> 
> J.O. has the right idea.  The way to do this is to store the data in the 
> $_SESSION variable to pass it on to the next page.

You have the thread "Replace punctuation in an associative array" where 
you can see an example on how it could be possible to work with the 
session, I do not claim it's the best solution, but based on the 
"requirements", it's a good solution for a half hour work.


> This is especially true if it has things like prices - which the user 
> can change if you give them access to it via a web page.

Yeah, I tend to favor to take prices from the database each time, this 
more to keep the prices up to date, as then if someone changes a price 
on a product that price change will get trough at once on all orders 
that are not finalized.

-- 
  //Aho

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

#19469

On 5/19/23 20:27, J.O. Aho wrote:
> On 5/19/23 17:56, Jerry Stuckle wrote:
>> On 5/19/2023 2:19 AM, Liz Tuddenham wrote:
>>> J.O. Aho <user@example.net> wrote:
>>>
>>>> On 5/18/23 23:38, The Doctor wrote:
>>>>> In article <kcn3tdFehn1U1@mid.individual.net>,
>>>>> J.O. Aho <user@example.net> wrote:
>>>>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>>>>> I need to send a 2-dimensional array from one file to another by 
>>>>>>> POST.
>>>>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>>>>
>>>>>>> I have tried :
>>>>>>>     Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>>>>> with
>>>>>>> $item = stripslashes($_POST['item']);
>>>>>>> but it does not work.
>>>>>>>
>>>>>>>     Any suggestions?
>>>>>>
>>>>>> 1. use session, store the value in the session and then use it in the
>>>>>> next page directly from the session.
>>>>>>
>>>>>> 2. serialize the variable and base64 encode the serialized data, post
>>>>>> this in the form and then base64 decode and unserialize.
>>>>>>
>>>>>
>>>>> Is base64 strong enugh?
>>>>
>>>> It's not about the encryption, it's about not making the html to break
>>>> as you don't know what the serialized data may contain.
>>>>
>>>> if the data is sensitive or you want to avoid user manipulation of the
>>>> data, then store the data in session and that is way it was number 1 of
>>>> the suggestions.
>>>
>>> The data isn't particularly sensitive, it is just a 'shopping list'
>>> passed from one part of a shopping program to another.  It could have
>>> been sent as dozens of individual variables, but that seemed clumsy as
>>> they were already nicely wrapped up in an array.
>>>
>>>
>>
>> J.O. has the right idea.  The way to do this is to store the data in 
>> the $_SESSION variable to pass it on to the next page.
> 
> You have the thread "Replace punctuation in an associative array" where 
> you can see an example on how it could be possible to work with the 
> session, I do not claim it's the best solution, but based on the 
> "requirements", it's a good solution for a half hour work.
> 
> 
>> This is especially true if it has things like prices - which the user 
>> can change if you give them access to it via a web page.
> 
> Yeah, I tend to favor to take prices from the database each time, this 
> more to keep the prices up to date, as then if someone changes a price 
> on a product that price change will get trough at once on all orders 
> that are not finalized.

Sorry, thought I replied to Liz, the two section I write was more 
intended for her than replaying to you.

-- 
  //Aho

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

#19475

On 5/19/2023 2:29 PM, J.O. Aho wrote:
> On 5/19/23 20:27, J.O. Aho wrote:
>> On 5/19/23 17:56, Jerry Stuckle wrote:
>>> On 5/19/2023 2:19 AM, Liz Tuddenham wrote:
>>>> J.O. Aho <user@example.net> wrote:
>>>>
>>>>> On 5/18/23 23:38, The Doctor wrote:
>>>>>> In article <kcn3tdFehn1U1@mid.individual.net>,
>>>>>> J.O. Aho <user@example.net> wrote:
>>>>>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>>>>>> I need to send a 2-dimensional array from one file to another by 
>>>>>>>> POST.
>>>>>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>>>>>
>>>>>>>> I have tried :
>>>>>>>>     Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>>>>>> with
>>>>>>>> $item = stripslashes($_POST['item']);
>>>>>>>> but it does not work.
>>>>>>>>
>>>>>>>>     Any suggestions?
>>>>>>>
>>>>>>> 1. use session, store the value in the session and then use it in 
>>>>>>> the
>>>>>>> next page directly from the session.
>>>>>>>
>>>>>>> 2. serialize the variable and base64 encode the serialized data, 
>>>>>>> post
>>>>>>> this in the form and then base64 decode and unserialize.
>>>>>>>
>>>>>>
>>>>>> Is base64 strong enugh?
>>>>>
>>>>> It's not about the encryption, it's about not making the html to break
>>>>> as you don't know what the serialized data may contain.
>>>>>
>>>>> if the data is sensitive or you want to avoid user manipulation of the
>>>>> data, then store the data in session and that is way it was number 
>>>>> 1 of
>>>>> the suggestions.
>>>>
>>>> The data isn't particularly sensitive, it is just a 'shopping list'
>>>> passed from one part of a shopping program to another.  It could have
>>>> been sent as dozens of individual variables, but that seemed clumsy as
>>>> they were already nicely wrapped up in an array.
>>>>
>>>>
>>>
>>> J.O. has the right idea.  The way to do this is to store the data in 
>>> the $_SESSION variable to pass it on to the next page.
>>
>> You have the thread "Replace punctuation in an associative array" 
>> where you can see an example on how it could be possible to work with 
>> the session, I do not claim it's the best solution, but based on the 
>> "requirements", it's a good solution for a half hour work.
>>
>>
>>> This is especially true if it has things like prices - which the user 
>>> can change if you give them access to it via a web page.
>>
>> Yeah, I tend to favor to take prices from the database each time, this 
>> more to keep the prices up to date, as then if someone changes a price 
>> on a product that price change will get trough at once on all orders 
>> that are not finalized.
> 
> Sorry, thought I replied to Liz, the two section I write was more 
> intended for her than replaying to you.
> 

No problem.  I knew what you meant :)

-- 
==================
Remove the "x"'s from my email address
Jerry Stuckle
stucklex.jerryx@gmail.com
==================

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

#19470

J.O. Aho <user@example.net> wrote:

[...]
> Yeah, I tend to favor to take prices from the database each time, this
> more to keep the prices up to date, as then if someone changes a price
> on a product that price change will get trough at once on all orders 
> that are not finalized.

Unfortunately that could lead to an illegal situation in the UK.  The
price has to be the one the user agreed to at the instant of clicking
the button.  If the database has been updated between there and the
checkout, the original price must still be charged.  (An unlikely
scenario, but one with potentially very damaging consequences.)

The agreed-to price is carried through the transaction by a cookie, the
small risk of tampering (and the low value of the goods) make this an
acceptable risk.  The final account is e-mailed to the dispatcher, so
any price anomalies ought to be caught at that stage.  (This is a small
voluntary organisation with a very limited range of stock, so errors
should be easy to spot.)


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

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

#19471

On 5/19/23 21:38, Liz Tuddenham wrote:
> J.O. Aho <user@example.net> wrote:
> 
> [...]
>> Yeah, I tend to favor to take prices from the database each time, this
>> more to keep the prices up to date, as then if someone changes a price
>> on a product that price change will get trough at once on all orders
>> that are not finalized.
> 
> Unfortunately that could lead to an illegal situation in the UK.  The
> price has to be the one the user agreed to at the instant of clicking
> the button.  If the database has been updated between there and the
> checkout, the original price must still be charged.  (An unlikely
> scenario, but one with potentially very damaging consequences.)

Sure you shouldn't change price when the end customer agrees on the cost 
and is sent to the payment page, at this point you can't change the 
price, but until the customer can at any point decide that the updated 
price isn't what they are prepared to pay for the product and remove it 
from the cart. Of course it's a good thing to notify if the price would 
change, one site that does this is amazon.co.uk.


> The agreed-to price is carried through the transaction by a cookie, the
> small risk of tampering (and the low value of the goods) make this an
> acceptable risk. 

I would fire anyone in my team if they would say it's an acceptable 
risk, values of a product, no matter if it's small and insignificant, 
shouldn't ever be end user adjustable and when it comes out that you can 
adjust the price, then people will start doing that and it's kind of a 
simple thing to do nowadays with all the browser extensions.


> The final account is e-mailed to the dispatcher, so
> any price anomalies ought to be caught at that stage.  (This is a small
> voluntary organisation with a very limited range of stock, so errors
> should be easy to spot.)

There are times when you have someone new, so mistakes can easily be done.
Do not downplay the risk just for it's a small organization and limited 
stock, tend to be those who has most to loose if someone manage to cheat.

-- 
  //Aho

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

#19473

On 5/19/2023 5:58 PM, J.O. Aho wrote:
> On 5/19/23 21:38, Liz Tuddenham wrote:
>> J.O. Aho <user@example.net> wrote:
>> [...]
>>> Yeah, I tend to favor to take prices from the database each time, this
>>> more to keep the prices up to date, as then if someone changes a price
>>> on a product that price change will get trough at once on all orders
>>> that are not finalized.
>>
>> Unfortunately that could lead to an illegal situation in the UK.  The
>> price has to be the one the user agreed to at the instant of clicking
>> the button.  If the database has been updated between there and the
>> checkout, the original price must still be charged.  (An unlikely
>> scenario, but one with potentially very damaging consequences.)
> 
> Sure you shouldn't change price when the end customer agrees on the cost 
> and is sent to the payment page, at this point you can't change the 
> price, but until the customer can at any point decide that the updated 
> price isn't what they are prepared to pay for the product and remove it 
> from the cart. Of course it's a good thing to notify if the price would 
> change, one site that does this is amazon.co.uk.

Different business rules require different supporting functionality:

use current price => nothing special needed

use price customer saw => get that and verify that it is correct (not 
tampered with)

remove item and inform user => need to detect situation

>> The agreed-to price is carried through the transaction by a cookie, the
>> small risk of tampering (and the low value of the goods) make this an
>> acceptable risk. 
 >
> I would fire anyone in my team if they would say it's an acceptable 
> risk, values of a product, no matter if it's small and insignificant, 
> shouldn't ever be end user adjustable and when it comes out that you can 
> adjust the price, then people will start doing that and it's kind of a 
> simple thing to do nowadays with all the browser extensions.

Yes.

If the rumor spread on the internet that there is a web site selling
anything where customers can hack the price and get it for that price,
then I suspect they will get tens of thousands of new "customers"
very quickly.

Arne

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

#19477

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:

> On 5/19/2023 5:58 PM, J.O. Aho wrote:
> > On 5/19/23 21:38, Liz Tuddenham wrote:
> >> J.O. Aho <user@example.net> wrote:
> >> [...]
> >>> Yeah, I tend to favor to take prices from the database each time, this
> >>> more to keep the prices up to date, as then if someone changes a price
> >>> on a product that price change will get trough at once on all orders
> >>> that are not finalized.
> >>
> >> Unfortunately that could lead to an illegal situation in the UK.  The
> >> price has to be the one the user agreed to at the instant of clicking
> >> the button.  If the database has been updated between there and the
> >> checkout, the original price must still be charged.  (An unlikely
> >> scenario, but one with potentially very damaging consequences.)
> > 
> > Sure you shouldn't change price when the end customer agrees on the cost
> > and is sent to the payment page, at this point you can't change the
> > price, but until the customer can at any point decide that the updated
> > price isn't what they are prepared to pay for the product and remove it
> > from the cart. Of course it's a good thing to notify if the price would
> > change, one site that does this is amazon.co.uk.
> 
> Different business rules require different supporting functionality:
> 
> use current price => nothing special needed
> 
> use price customer saw => get that and verify that it is correct (not
> tampered with)
> 
> remove item and inform user => need to detect situation
> 
> >> The agreed-to price is carried through the transaction by a cookie, the
> >> small risk of tampering (and the low value of the goods) make this an
> >> acceptable risk. 
>  >
> > I would fire anyone in my team if they would say it's an acceptable
> > risk, values of a product, no matter if it's small and insignificant,
> > shouldn't ever be end user adjustable and when it comes out that you can
> > adjust the price, then people will start doing that and it's kind of a
> > simple thing to do nowadays with all the browser extensions.
> 
> Yes.
> 
> If the rumor spread on the internet that there is a web site selling
> anything where customers can hack the price and get it for that price,
> then I suspect they will get tens of thousands of new "customers"
> very quickly.

We might notice, our sales are less than £150 per year.


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

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

#19478

On Sat, 20 May 2023 09:56:34 Liz Tuddenham wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 5/19/2023 5:58 PM, J.O. Aho wrote:
>> > On 5/19/23 21:38, Liz Tuddenham wrote:
>> >> The agreed-to price is carried through the transaction by a
>> >> cookie, the small risk of tampering (and the low value of the
>> >> goods) make this an acceptable risk. 

>> > I would fire anyone in my team if they would say it's an
>> > acceptable risk, values of a product, no matter if it's small
>> > and insignificant, shouldn't ever be end user adjustable and
>> > when it comes out that you can adjust the price, then people
>> > will start doing that and it's kind of a simple thing to do
>> > nowadays with all the browser extensions.

>> Yes.
> 
>> If the rumor spread on the internet that there is a web site
>> selling anything where customers can hack the price and get it
>> for that price, then I suspect they will get tens of thousands of
>> new "customers" very quickly.

> We might notice, our sales are less than £150 per year.

While I agree that - given these circumstances - there is most
likely no commercial risk at all, it is still bad practice to do so
and (most important in your case) is not even easier in your case,
so I can see no advantages but potential problems, even if they are
highly unlikely.

Bye,
Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Pummelig und ölig!
(Sloganizer)

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

#19474

On 5/19/2023 2:27 PM, J.O. Aho wrote:
> On 5/19/23 17:56, Jerry Stuckle wrote:
>> On 5/19/2023 2:19 AM, Liz Tuddenham wrote:
>>> J.O. Aho <user@example.net> wrote:
>>>
>>>> On 5/18/23 23:38, The Doctor wrote:
>>>>> In article <kcn3tdFehn1U1@mid.individual.net>,
>>>>> J.O. Aho <user@example.net> wrote:
>>>>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>>>>> I need to send a 2-dimensional array from one file to another by 
>>>>>>> POST.
>>>>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>>>>
>>>>>>> I have tried :
>>>>>>>     Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>>>>> with
>>>>>>> $item = stripslashes($_POST['item']);
>>>>>>> but it does not work.
>>>>>>>
>>>>>>>     Any suggestions?
>>>>>>
>>>>>> 1. use session, store the value in the session and then use it in the
>>>>>> next page directly from the session.
>>>>>>
>>>>>> 2. serialize the variable and base64 encode the serialized data, post
>>>>>> this in the form and then base64 decode and unserialize.
>>>>>>
>>>>>
>>>>> Is base64 strong enugh?
>>>>
>>>> It's not about the encryption, it's about not making the html to break
>>>> as you don't know what the serialized data may contain.
>>>>
>>>> if the data is sensitive or you want to avoid user manipulation of the
>>>> data, then store the data in session and that is way it was number 1 of
>>>> the suggestions.
>>>
>>> The data isn't particularly sensitive, it is just a 'shopping list'
>>> passed from one part of a shopping program to another.  It could have
>>> been sent as dozens of individual variables, but that seemed clumsy as
>>> they were already nicely wrapped up in an array.
>>>
>>>
>>
>> J.O. has the right idea.  The way to do this is to store the data in 
>> the $_SESSION variable to pass it on to the next page.
> 
> You have the thread "Replace punctuation in an associative array" where 
> you can see an example on how it could be possible to work with the 
> session, I do not claim it's the best solution, but based on the 
> "requirements", it's a good solution for a half hour work.
> 
> 
>> This is especially true if it has things like prices - which the user 
>> can change if you give them access to it via a web page.
> 
> Yeah, I tend to favor to take prices from the database each time, this 
> more to keep the prices up to date, as then if someone changes a price 
> on a product that price change will get trough at once on all orders 
> that are not finalized.
> 

I don't like taking prices from the database each time.  If the price 
goes up, people will complain about "bait and switch".  I get them from 
the database once and store them in the session.  That way if the price 
changes they still have the old price.

Of course I also keep a fairly short session timeout (a few hours at 
most) so if they come back six months later they don't get an old price.

-- 
==================
Remove the "x"'s from my email address
Jerry Stuckle
stucklex.jerryx@gmail.com
==================

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

#19472

On 5/18/2023 5:44 PM, J.O. Aho wrote:
> On 5/18/23 23:38, The Doctor wrote:
>> In article <kcn3tdFehn1U1@mid.individual.net>,
>> J.O. Aho <user@example.net> wrote:
>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>> I need to send a 2-dimensional array from one file to another by POST.
>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>
>>>> I have tried :
>>>>    Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>> with
>>>> $item = stripslashes($_POST['item']);
>>>> but it does not work.
>>>>
>>>>    Any suggestions?
>>>
>>> 1. use session, store the value in the session and then use it in the
>>> next page directly from the session.
>>>
>>> 2. serialize the variable and base64 encode the serialized data, post
>>> this in the form and then base64 decode and unserialize.
>>>
>>
>> Is base64 strong enugh?
> 
> It's not about the encryption, it's about not making the html to break 
> as you don't know what the serialized data may contain.
> 
> if the data is sensitive or you want to avoid user manipulation of the 
> data, then store the data in session and that is way it was number 1 of 
> the suggestions.

The concept of "page scope" or "view state" is well
known in some other technologies (like ASP.NET and JSF).
That may end up as a HTML hidden field like this.

In such cases it should always be secured cryptographic
(MAC etc.). Frameworks that supports page scope / view state
via hidden field usually have this enabled by default.

Given that this is not supported out of the box in PHP
(I have no idea whether any of the well known PHP MVC
frameworks offer such support), then it is not an
easy solution to implement.

So using session absolutely looks like the path of least
resistance.

But people should be aware that switching from page
scope to session scope is only transparent in 99.9% or
so of cases. There are (rare) cases where it will impact
functionality.

Arne

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

#19476

On 5/19/2023 9:30 PM, Arne Vajhøj wrote:
> On 5/18/2023 5:44 PM, J.O. Aho wrote:
>> On 5/18/23 23:38, The Doctor wrote:
>>> In article <kcn3tdFehn1U1@mid.individual.net>,
>>> J.O. Aho <user@example.net> wrote:
>>>> On 5/18/23 18:04, Liz Tuddenham wrote:
>>>>> I need to send a 2-dimensional array from one file to another by POST.
>>>>> The array is $item[][] with contents that are entirelyintegers.
>>>>>
>>>>> I have tried :
>>>>>    Print "<INPUT TYPE=hidden NAME=item[] VALUE=$item>";
>>>>> with
>>>>> $item = stripslashes($_POST['item']);
>>>>> but it does not work.
>>>>>
>>>>>    Any suggestions?
>>>>
>>>> 1. use session, store the value in the session and then use it in the
>>>> next page directly from the session.
>>>>
>>>> 2. serialize the variable and base64 encode the serialized data, post
>>>> this in the form and then base64 decode and unserialize.
>>>>
>>>
>>> Is base64 strong enugh?
>>
>> It's not about the encryption, it's about not making the html to break 
>> as you don't know what the serialized data may contain.
>>
>> if the data is sensitive or you want to avoid user manipulation of the 
>> data, then store the data in session and that is way it was number 1 
>> of the suggestions.
> 
> The concept of "page scope" or "view state" is well
> known in some other technologies (like ASP.NET and JSF).
> That may end up as a HTML hidden field like this.
> 
> In such cases it should always be secured cryptographic
> (MAC etc.). Frameworks that supports page scope / view state
> via hidden field usually have this enabled by default.
> 
> Given that this is not supported out of the box in PHP
> (I have no idea whether any of the well known PHP MVC
> frameworks offer such support), then it is not an
> easy solution to implement.
> 
> So using session absolutely looks like the path of least
> resistance.
> 
> But people should be aware that switching from page
> scope to session scope is only transparent in 99.9% or
> so of cases. There are (rare) cases where it will impact
> functionality.
> 
> Arne
> 
> 
> 
> 
> 

If the data is sensitive, such as prices, it shouldn't even be sent to 
the user, encrypted or not.  That's what the $_SESSION variable is for.

-- 
==================
Remove the "x"'s from my email address
Jerry Stuckle
stucklex.jerryx@gmail.com
==================

[toc] | [prev] | [standalone]

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

csiph-web