救命!后退按钮 - 重新设计项目??? [英] Help! Back button - Redesign Project???

查看:56
本文介绍了救命!后退按钮 - 重新设计项目???的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你好 -


以为我差不多完成了我的项目然后一个后退箭头按钮问题

抬起它丑陋的脑袋。


一旦用户填写表格并提交表格(通过存储过程完成到
a Sql Server数据库),有什么可以防止他们按下后退按钮

并多次重新提交表单并对我的数据库造成破坏?

这个问题通常是如何处理的?


任何帮助都将是非常感谢!

-

Sandy

Hello -

Thought I was almost done with my project and then a back arrow button issue
raised its ugly head.

Once a user fills out a form and submits it (done via stored procedure into
a Sql Server database), what''s to prevent them from pressing the back button
and resubmitting the form multiple times and creating havoc with my database?
How is this issue usually handled?

Any help will be greatly appreciated!
--
Sandy

推荐答案

Sandy,


保护数据库的最佳方法是在

数据库中建立保护。您是否有适当的主键和唯一索引

在您的数据库中指定?如果没有,你一定要把它们放在

里。


一个独特的索引可以保护你免受插入重复记录的用户

in后续帖子。具有相同

数据的表单的后续提交可能会违反您的一个约束,并且不会插入任何重复的

记录。可以向用户返回一个错误,说明发生了什么事情。


对于更新,请在表格上使用并行ID,每个增量都会增加


每条记录的连续更新。您可以使用触发器来增加

。在您的更新过程中,检查表单中的

并发ID的值(您可以将其存储在隐藏文本

字段中)。如果它不等于数据库中

选定记录的值,则您的程序可以返回错误,可以向用户显示

。使用后退按钮将始终返回一个

过时的并发ID,并且永远不会导致更新。这个

技术还可以保护您免受用户覆盖另一个用户所做的更改
的情况。


我认为确保数据库级别的完整性优于

在应用程序中这样做。如果您依赖应用程序和用户

从应用程序外部访问数据,则无法保护。


您要做的最后一件事是用

用户的浏览器开始摔跤。


比尔E.

Sandy,

The best way to protect the database is to build protection into the
database. Do you have primary keys and unique indexes appropriately
designated in your database? If not, you should definitely put them
in.

A unique index can protect you from users inserting duplicate records
in subsequent posts. Subsequent submittals of the form with the same
data would likely violate one of your constraints and no duplicate
record would be inserted. An error can be returned to the user stating
what happened.

For updates, use a concurrency ID on the table that increments for each
successive update for each record. You can use a trigger to do the
incrementing. In your update procedure, check for the value of the
concurrency ID as it is in the form (you can store it in a hidden text
field). If it is not equal to the value in the database for the
selected record, your procedure can return an error, which can be
displayed to the user. Use of the back button will always return an
obsolete concurrency ID and will never result in an update. This
technique will also protect you from cases where a user overwrites
changes made by another user.

I think that ensuring integrity at the database level is preferable to
doing so in the application. If you rely on the application and users
access the data from outside the application, you have no protection.

The last thing that you want to do is to start wrestling with the
user''s browser.

Bill E.


re:
这个问题通常是如何处理的?


不接受数据库中的重复记录。


Juan T. Llibre

ASP.NET MVP
http://asp.net.do/foros/

Foros de ASP.NET en Espa?ol

Ven,y hablemos de ASP.NET ...

======== ==============


" Sandy" <萨*** @ discussions.microsoft.com>在消息中写道

新闻:4B ********************************** @ microsof t.com ...你好 -

以为我差不多完成了我的项目,然后一个后退箭头按钮
问题
提出了它的丑陋头脑。
到Sql Server数据库),有什么可以阻止他们按下后面的
按钮数据库造成破坏?
这个问题通常如何处理?

任何帮助都将不胜感激!
- -
Sandy
How is this issue usually handled?
By not accepting duplicate records in the database.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Espa?ol
Ven, y hablemos de ASP.NET...
======================

"Sandy" <Sa***@discussions.microsoft.com> wrote in message
news:4B**********************************@microsof t.com... Hello -

Thought I was almost done with my project and then a back arrow button
issue
raised its ugly head.

Once a user fills out a form and submits it (done via stored procedure
into
a Sql Server database), what''s to prevent them from pressing the back
button
and resubmitting the form multiple times and creating havoc with my
database?
How is this issue usually handled?

Any help will be greatly appreciated!
--
Sandy



感谢您的回复,比尔。我该怎么做呢?这是我的

表:


CREATE TABLE [tblPost](

[PostID] [int] IDENTITY(1 ,1)NOT NULL,

[UserID] [int] NOT NULL,

[TopicID] [int] NOT NULL,

[问题] [char](100)COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,

[PostMsg] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

[PostDT] [datetime] NOT NULL CONSTRAINT [DF_tblPost_PostDT]默认

(getdate()),

CONSTRAINT [PK_tblPost] PRIMARY KEY CLUSTERED



[PostID]

)ON [PRIMARY]

)ON [主要]


这是我的存储过程:


ALTER过程spInsertPostMsg

@UserID int,

@TopicID int,

@Question char(100),

@ PostMsg text,

@PostDT datetime =默认,

@PostID int OUTPUT

AS

插入到tblPost





@UserID,

@TopicID,

@Question,

@ PostMsg,

GetDate()



声明@Ident int

选择@PostID = @@ IDENTITY

选择@Ident = @PostID

**** **************
Thanks for your response, Bill. How would I go about doing that? Here''s my
table:

CREATE TABLE [tblPost] (
[PostID] [int] IDENTITY (1, 1) NOT NULL ,
[UserID] [int] NOT NULL ,
[TopicID] [int] NOT NULL ,
[Question] [char] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[PostMsg] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[PostDT] [datetime] NOT NULL CONSTRAINT [DF_tblPost_PostDT] DEFAULT
(getdate()),
CONSTRAINT [PK_tblPost] PRIMARY KEY CLUSTERED
(
[PostID]
) ON [PRIMARY]
) ON [PRIMARY]

Here''s my stored procedure:

ALTER Procedure spInsertPostMsg
@UserID int,
@TopicID int,
@Question char(100),
@PostMsg text,

@PostDT datetime = Default,
@PostID int OUTPUT
AS
Insert into tblPost
Values
(
@UserID,
@TopicID,
@Question,
@PostMsg,
GetDate()
)
Declare @Ident int
Select @PostID = @@IDENTITY
Select @Ident = @PostID
******************
一个独特的索引可以保护您免受后续帖子中插入重复记录的用户的影响。具有相同
数据的表单的后续提交可能会违反您的一个约束,并且不会插入重复的
记录。可以向用户返回错误,说明发生了什么。


我有一个日期/时间栏 - 条目永远不会相同。我的

逻辑是否存在缺陷?此外,此表格不会更新 - 只需添加新的

条目。


我同意这应该在数据库级别完成 - 也许在两个级别将

成为更好的解决方案。 。 。


再次感谢!


Sandy


" bi ****** **@netscape.net"写道:

Sandy,

保护数据库的最佳方法是在
数据库中建立保护。您是否在数据库中指定了主键和唯一索引?如果没有,你一定要把它们放进去。

一个独特的索引可以保护你免受用户在后续帖子中插入重复记录的影响。具有相同
数据的表单的后续提交可能会违反您的一个约束,并且不会插入重复的
记录。可以向用户返回错误,说明发生了什么。

对于更新,请在表上使用并发ID,每个记录的每次连续更新都会增加。您可以使用触发器来进行递增。在您的更新过程中,检查表单中的并发ID值(您可以将其存储在隐藏文本
字段中)。如果它不等于数据库中所选记录的值,则您的过程可以返回错误,该错误可以显示给用户。使用后退按钮将始终返回一个过时的并发ID,并且永远不会导致更新。这种技术还可以保护您免受用户覆盖其他用户所做更改的情况的影响。

我认为确保数据库级别的完整性比
更好在应用程序中这样做。如果您依赖应用程序并且用户从应用程序外部访问数据,则无法提供保护。

您要做的最后一件事就是开始与
用户的浏览器。

比尔E.
A unique index can protect you from users inserting duplicate records
in subsequent posts. Subsequent submittals of the form with the same
data would likely violate one of your constraints and no duplicate
record would be inserted. An error can be returned to the user stating
what happened.
I have a date/time column - the entries would never be the same. Is my
logic flawed on this? Also, this table will not be updated - just new
entries added.

I agree this should be done at the DB level -- perhaps at both levels would
be an even better solution . . .

Thanks again!

Sandy

"bi********@netscape.net" wrote:
Sandy,

The best way to protect the database is to build protection into the
database. Do you have primary keys and unique indexes appropriately
designated in your database? If not, you should definitely put them
in.

A unique index can protect you from users inserting duplicate records
in subsequent posts. Subsequent submittals of the form with the same
data would likely violate one of your constraints and no duplicate
record would be inserted. An error can be returned to the user stating
what happened.

For updates, use a concurrency ID on the table that increments for each
successive update for each record. You can use a trigger to do the
incrementing. In your update procedure, check for the value of the
concurrency ID as it is in the form (you can store it in a hidden text
field). If it is not equal to the value in the database for the
selected record, your procedure can return an error, which can be
displayed to the user. Use of the back button will always return an
obsolete concurrency ID and will never result in an update. This
technique will also protect you from cases where a user overwrites
changes made by another user.

I think that ensuring integrity at the database level is preferable to
doing so in the application. If you rely on the application and users
access the data from outside the application, you have no protection.

The last thing that you want to do is to start wrestling with the
user''s browser.

Bill E.



这篇关于救命!后退按钮 - 重新设计项目???的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆