On Oct 25, 4:26 am, Brian M wrote:
> It may not be a
> concern for your app, but it is something to consider.
You raise some very interesting points. I am probably not going to
design anything for these kinds of situations right now, simply due to
lack of time, but I'll certainly keep it in mind
If you're looking up off of a session variable, be sure to take into
account what might happen if a user happens to have your site open in
multiple windows/tabs. What if you've got a client looking for room
rates in different tabs for two different dates or rooms trying to do
some comparison shopp
On Oct 24, 9:48 pm, Brian M wrote:
> How about include all the calculated values in your form and add in an
> additional field that's a HMAC keyed hash of the others using a key
> that only you know? When the user submits, make sure the rest of the
> field values still combine & hash the same way
On Oct 24, 9:41 pm, Branko Vukelic wrote:
> Oh, so ok, I get what you're trying to do now. Don't pass charge
> amount around. Charge amount should be one-way. You NEVER, under ANY
> circumstances, using ANY technology, expect that amount to come from
> client side.
Yes, I guess that should have b
This could be a default feature Let me give it some thought..
On Oct 24, 2:48 pm, Brian M wrote:
> How about include all the calculated values in your form and add in an
> additional field that's a HMAC keyed hash of the others using a key
> that only you know? When the user submits, make sur
How about include all the calculated values in your form and add in an
additional field that's a HMAC keyed hash of the others using a key
that only you know? When the user submits, make sure the rest of the
field values still combine & hash the same way and then you'll know
the user hasn't messed
On Sun, Oct 24, 2010 at 8:41 PM, cjrh wrote:
> On Oct 24, 5:03 pm, Branko Vukelic wrote:
>> * Calculated values are shown, and a form with hidden fields and a
>> submit button labeled 'Confirm' is shown
>
> The hidden fields still show in the page source though. A smart user
> could submit his o
On Oct 24, 5:03 pm, Branko Vukelic wrote:
> * Calculated values are shown, and a form with hidden fields and a
> submit button labeled 'Confirm' is shown
The hidden fields still show in the page source though. A smart user
could submit his own set of data if he can see what field id's are
being
On Sun, Oct 24, 2010 at 4:43 PM, cjrh wrote:
> The datum in my case is a room rate that a client must pay.
> Recalculation is somewhat complicated, and I had hoped to avoid a
> recalculation and just pass the already-calculated value to the
> "confirmation" page. I cannot let that be part of the
On Oct 24, 4:43 pm, cjrh wrote:
> So as I said, looks like the safest is for me to simply calculate the
> rate again.
On the server-side, I mean. Dunno if that was clear.
On Oct 24, 4:29 pm, Branko Vukelic wrote:
> Since
> you say the data is already in the table on the page, there's no point
> in trying to hide it, especially since POST isn't really hiding
> anything if someone really wants to get ahold of request data.
The datum in my case is a room rate that a
On Sun, Oct 24, 2010 at 4:16 PM, cjrh wrote:
> I want to know if there is a way to get data to go from a page to a
> controller function via an HTTP link, rather than using a form, and
> without showing that data on the URL.
AFAIK, you only get to use two HTTP methods (regardless of whether
AJAX
On Oct 24, 3:23 pm, Branko Vukelic wrote:
> It might help if you could show us the table. I'm still not sure I
> understand what you're trying to do.
There are three ways (that I know of) to get data to be available in
successive controller functions:
1) Pass it on the URL as arguments
2) Write
On Sun, Oct 24, 2010 at 12:16 PM, cjrh wrote:
> It all now works as expected, however, I remain unsure about this as a
> viable strategy anyway. I would love to hear about best practice here.
It might help if you could show us the table. I'm still not sure I
understand what you're trying to do.
On Oct 24, 1:56 am, cjrh wrote:
> Would I have to use javascript?
>
> My tests below doesn't seem to permanently update the session object
> inside setnum(), even though request.args does contain the number sent
> by ajax. Inside showme(), the session value is default once again,
> making me thin
On Oct 24, 2:20 am, Branko Vukelic wrote:
> How is the data 'associated' with the link?
Say I have a table of 10 items. In each row, there is a link to the
same URL. However, I want to access row-specific data in the target
controller function, without supplying that data through the URL
itsel
On Sun, Oct 24, 2010 at 2:17 AM, cjrh wrote:
> On Oct 24, 1:56 am, cjrh wrote:
>> My tests below doesn't seem to permanently update the session object
>> inside setnum(), even though request.args does contain the number sent
>> by ajax.
>
> Ok, I figured out that the $.ajax() call doesn't send a
On Oct 24, 1:56 am, cjrh wrote:
> My tests below doesn't seem to permanently update the session object
> inside setnum(), even though request.args does contain the number sent
> by ajax.
Ok, I figured out that the $.ajax() call doesn't send a cookie, so the
session object inside setnum() is an en
18 matches
Mail list logo
