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

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

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

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

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

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
==================

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

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

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

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

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

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

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
==================

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
==================

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
==================

=?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

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)