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?
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.
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?
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
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
=?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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 349 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 118:54:42 |
| Calls: | 7,612 |
| Files: | 12,787 |
| Messages: | 5,684,026 |