Why is this idea bad?

I was trying to think of ways to stop accidental reposts of data when users
hit the back button and I came up with an idea.
If I were to tag every response that I send to the client with a guid and
then store that guid in a database I could check on the postback to see if
that request has already been posted. If it has been posted I would just do
a response.redirect to the page so people get a fresh version of it. If it'
s
the first post back I could delete the guid from the database as being a
valid response. I would also have to timestamp each entry to allow them to
expire after a certain time. I was thinking that I would store the guids in
sql server.
This idea seems too much of a magic bullet for the re-postback problem, what
is wrong with it?
Thanks, Scott> This idea seems too much of a magic bullet for the re-postback problem,
> what
> is wrong with it?
it is not scalable. you incur a database lookup for every post request per
customer. multiply that by a few users and your database will be underload
even when no real work is being done.
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
>I was trying to think of ways to stop accidental reposts of data when users
> hit the back button and I came up with an idea.
> If I were to tag every response that I send to the client with a guid and
> then store that guid in a database I could check on the postback to see if
> that request has already been posted. If it has been posted I would just
> do
> a response.redirect to the page so people get a fresh version of it. If
> it's
> the first post back I could delete the guid from the database as being a
> valid response. I would also have to timestamp each entry to allow them
> to
> expire after a certain time. I was thinking that I would store the guids
> in
> sql server.
> This idea seems too much of a magic bullet for the re-postback problem,
> what
> is wrong with it?
> Thanks, Scott
i use the same approach, it it works well. the major work, it gracefully
handling the extra post, say the point was to update data and navigate to a
new page, you want to do the navigate, but not the update.
-- bruce (sqlwork.com)
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
> I was trying to think of ways to stop accidental reposts of data when
users
> hit the back button and I came up with an idea.
> If I were to tag every response that I send to the client with a guid and
> then store that guid in a database I could check on the postback to see if
> that request has already been posted. If it has been posted I would just
do
> a response.redirect to the page so people get a fresh version of it. If
it's
> the first post back I could delete the guid from the database as being a
> valid response. I would also have to timestamp each entry to allow them
to
> expire after a certain time. I was thinking that I would store the guids
in
> sql server.
> This idea seems too much of a magic bullet for the re-postback problem,
what
> is wrong with it?
> Thanks, Scott
This is not a bad idea, especially on pages where double posting would be
very bad.
For instance, if you have a page that allows the user to make a payment of
some sort, you don't want them making accidentally making multiple payments.
In the Page_Load, if it's not a postback, you could store the guid in the
ViewState. When creating a payment, store the guid with the payment data an
d
check for duplicate guids as part of payment creation.
I can't imagine doing it for every page though.
Good Luck
"Scott Simons" wrote:

> I was trying to think of ways to stop accidental reposts of data when user
s
> hit the back button and I came up with an idea.
> If I were to tag every response that I send to the client with a guid and
> then store that guid in a database I could check on the postback to see if
> that request has already been posted. If it has been posted I would just
do
> a response.redirect to the page so people get a fresh version of it. If i
t's
> the first post back I could delete the guid from the database as being a
> valid response. I would also have to timestamp each entry to allow them t
o
> expire after a certain time. I was thinking that I would store the guids
in
> sql server.
> This idea seems too much of a magic bullet for the re-postback problem, wh
at
> is wrong with it?
> Thanks, Scott
Actually every page where this would be used already hits the database at
least once. Wouldn't this basically be the same thing as Microsoft's
suggestion to use sql server to store the state of the application.
"Alvin Bruney [MVP]" wrote:

> it is not scalable. you incur a database lookup for every post request per
> customer. multiply that by a few users and your database will be underload
> even when no real work is being done.
> --
> Regards,
> Alvin Bruney
> [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
> Got tidbits? Get it here... http://tinyurl.com/27cok
> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in messag
e
> news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
>
>
Hi Scott,
Looks like a good idea. If you are going to use it for every page you might
want to derive your own page class from System.Web.UI.Page. Generate the
GUID here and then inherit this page in all your pages. That way you'll
only have to write the GUID-creating code once. Good luck! Ken.
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
> I was trying to think of ways to stop accidental reposts of data when
users
> hit the back button and I came up with an idea.
> If I were to tag every response that I send to the client with a guid and
> then store that guid in a database I could check on the postback to see if
> that request has already been posted. If it has been posted I would just
do
> a response.redirect to the page so people get a fresh version of it. If
it's
> the first post back I could delete the guid from the database as being a
> valid response. I would also have to timestamp each entry to allow them
to
> expire after a certain time. I was thinking that I would store the guids
in
> sql server.
> This idea seems too much of a magic bullet for the re-postback problem,
what
> is wrong with it?
> Thanks, Scott
Use the same concept buy with a querystring value or hidden form field value
and you will completely circumvent the performance limitations of doing it
with a database.
1. First time the user hits a page, a querystring value is added to the url.
2. This querystring value is passed to every other page that the user might
go to.
3. The querystring value will grow as the pages accessed increases.
4. Each page could check a global shared function in Global.asax that checks
if the page has already been viewed based on the querystring value and
returns a boolean value.
5. If the function returns true, the page has already been viewed and you
can redirect them, if false, let the current page process.
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
>I was trying to think of ways to stop accidental reposts of data when users
> hit the back button and I came up with an idea.
> If I were to tag every response that I send to the client with a guid and
> then store that guid in a database I could check on the postback to see if
> that request has already been posted. If it has been posted I would just
> do
> a response.redirect to the page so people get a fresh version of it. If
> it's
> the first post back I could delete the guid from the database as being a
> valid response. I would also have to timestamp each entry to allow them
> to
> expire after a certain time. I was thinking that I would store the guids
> in
> sql server.
> This idea seems too much of a magic bullet for the re-postback problem,
> what
> is wrong with it?
> Thanks, Scott
well how about just taking the button on way on the click with clientside
code. that ensures just one post. if that is what you want to do. need to
re-read this thread again in a bit. but in the meantime, what's wrong with
this suggestion?
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
"Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in message
news:F67EB795-06D6-4CEF-B945-CA6524190627@.microsoft.com...
> Actually every page where this would be used already hits the database at
> least once. Wouldn't this basically be the same thing as Microsoft's
> suggestion to use sql server to store the state of the application.
> "Alvin Bruney [MVP]" wrote:
>
This wouldn't really scale across multiple servers well. Also, the user can
have multiple windows open at the same time. This is an adminstration site
for a client application.
"Scott M." wrote:

> Use the same concept buy with a querystring value or hidden form field val
ue
> and you will completely circumvent the performance limitations of doing it
> with a database.
> 1. First time the user hits a page, a querystring value is added to the ur
l.
> 2. This querystring value is passed to every other page that the user migh
t
> go to.
> 3. The querystring value will grow as the pages accessed increases.
> 4. Each page could check a global shared function in Global.asax that chec
ks
> if the page has already been viewed based on the querystring value and
> returns a boolean value.
> 5. If the function returns true, the page has already been viewed and you
> can redirect them, if false, let the current page process.
>
> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in messag
e
> news:F157D13A-A190-4A31-9BDE-8A97E3D608AA@.microsoft.com...
>
>
Taking away the submit button wouldn't work well for if they hit the back
button to get to another post back. In other words the user clicks the add
user button then edits the new user and clicks the save user button, when
they hit the back button after hitting the save button it will be
re-submitting the add user button. I can't just disable the add user button
because it could be a valid action if actually clicked. Most of the time
it's just that users hit the back button and ends up with another user.
"Alvin Bruney [MVP]" wrote:

> well how about just taking the button on way on the click with clientside
> code. that ensures just one post. if that is what you want to do. need to
> re-read this thread again in a bit. but in the meantime, what's wrong with
> this suggestion?
> --
> Regards,
> Alvin Bruney
> [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
> Got tidbits? Get it here... http://tinyurl.com/27cok
> "Scott Simons" <Scott.Simons.At.MealMagic.Com.Remove.This> wrote in messag
e
> news:F67EB795-06D6-4CEF-B945-CA6524190627@.microsoft.com...
>
>