会话和关闭浏览器 [英] Sessions and closing the browser
问题描述
小组的问题
我工作的网站的身份验证系统似乎正常运行
，一切都很好。会话跟踪所有内容并且
cookie用于接受或拒绝访问...听起来应该是我希望的。
然后当所有操作完成后退出摧毁一切，页面是
不再可访问。到目前为止还不错。
但是有两件事情可以想到：一个是防止多次登录
用户/密码。我读过的解决方案似乎是使用另一个
变量来检查用户是否已经登录（简单
是或否）。很简单。我想要正常退出并删除
所有值都会删除它，然后删除cookie。但是，如果
浏览器只是关闭了怎么办？如果我了解一切如何运作，那么cookie将会在一段时间内自动删除。
如果用户登录，关闭浏览器并尝试再次登录？
是否仍然存在登录已存在的值？或者我是否认为我需要一个已经透明的问题的解决方案
处理？
thx
（注意：我今天早些时候发了一封关于此的电子邮件，但是我没有看到它，所以我
再次发送它）
在文章< Xn ************************ @ 216.168.3.44>中，Theo写道：< blockquote class =post_quotes>小组的问题
我正在进行的网站的认证系统似乎正常运行，一切都很好。一个会话跟踪所有内容，并且
cookie用于接受或拒绝访问...我希望它应该是声音。
然后当完成所有操作时，注销会破坏所有内容并且页面是
不再可访问。到目前为止还不错。
但有两件事情浮现在脑海中：一是阻止多次登录
用户/密码。我读过的解决方案似乎是使用另一个
变量来检查用户是否已经登录（简单
是或否）。很简单。我想要正常退出并删除
所有值都会删除它，然后删除cookie。但是，如果
浏览器只是关闭怎么办？如果我了解一切如何运作，那么cookie将会在一段时间内自动删除。
如果用户登录，关闭浏览器并尝试再次登录该怎么办？
是否仍然存在登录已存在的值？或者我是否认为我需要一个已经透明处理的问题的解决方案？
而不是是/否存储时间戳。并将该时间戳保存在
会话中。
每次用户请求页面时，将会话时间戳与
时间戳进行比较在数据库中。
如果新登录完成，时间戳将不同。
-
Tim Van Wassenhove< http://www.timvw.info>
2004年9月24日星期五22:45:53 -0000，Theo< in *****@noemail.com>写道：
小组的问题
我工作的网站的认证系统似乎正常运作
并且一切都很好。一个会话跟踪所有内容，并且
cookie用于接受或拒绝访问...我希望它应该是声音。
然后当完成所有操作时，注销会破坏所有内容并且页面是
不再可访问。到目前为止还不错。
但有两件事情浮现在脑海中：一是阻止多次登录
用户/密码。我读过的解决方案似乎是使用另一个
变量来检查用户是否已经登录（简单
是或否）。很简单。我想要正常退出并删除
所有值都会删除它，然后删除cookie。但是，如果
浏览器只是关闭怎么办？如果我了解一切如何运作，那么cookie将会在一段时间内自动删除。
如果用户登录，关闭浏览器并尝试再次登录该怎么办？
是否仍然存在登录已存在的值？或者我是否认为我需要一个已经透明处理的问题的解决方案？
（注意：我发了一封电子邮件这个今天早些时候，但我没有看到它，所以我再次发送它）
对..所以你使用_SESSIONs或_COOKIEs？ （或两者兼而有之？）
默认情况下，两者都有相同的生命周期..
会话期间。当用户关闭浏览器时，_SESSION或_COOKIE数据
被删除（假设您没有使用cookie并设置指定的
到期日期）因此我相信你当用户关闭浏览器，_all_ session
数据将被销毁，包括''i_am_logged_in''值..无论你用什么
来区分=）
HTH。
问候，
Ian
-
Ian.H
digiServ网络
伦敦，英国
http://digiserv.net/
>我正在处理的网站的身份验证系统似乎正常运行并且一切都很好。一个会话跟踪所有内容，并且
cookie用于接受或拒绝访问...我希望它应该是声音。
然后当完成所有操作时，注销会破坏所有内容并且页面是
不再可访问。到目前为止还不错。
但有两件事情浮现在脑海中：一是阻止多次登录
用户/密码。
为什么？你想在这里解决什么问题？
如果意图是阻止付费网站登录的共享，那么你需要交易一个问题另一个（拒绝合法的
用户访问）。当然，网站运营商可能会喜欢这个问题，因为它的带宽成本更低。但是他可能会失去客户并且他的
网站可能会声名狼借。
如果意图是被遗弃会话的某种安全性或
计算机无人看管，在会话中加上时间戳。更新
每个成功加载页面时当前时间的时间戳（这是
部分在登录检查后出现）。在每个页面上，登录的
检查应该包括检查时间戳是否太旧
（无论你决定什么价值）。如果是（或登录是
，否则无效，例如，成员资格已过期），销毁会话
并重定向到登录页面。这应该照顾被遗弃的
会话：任何比超时更早的会话都没有任何好处，如果有人试图使用它们会被破坏他们。你还需要偶尔进行清理过程，删除旧的
会话，这些会话在被放弃后没有人试图使用
（主要用于回收磁盘）空间）。哦，是的，不要指望浏览器
在适当的时候删除cookie。有些台式机的时钟很好，很糟糕，很糟糕，而且可能需要几年时间。另外，嗅到的饼干
可能会在某个地方的另一台计算机上复活，并且会有一个不会像你期望的那样表现出来的浏览器。
您对太旧的定义应该考虑用户
对页面做了什么：如果一般用户需要15分钟
来填写一个表格或撰写消息文本，可能会超时
的20分钟太短了。
如果意图是某种假设，如果有重复的
登录，一个必须是一个未经授权的破解者或将搞砸你的
申请，嗯，这种假设往往是错误的。对于我来说，在几台计算机上运行多个浏览器并不常见。
在同一台显示器上查看同一个站点。您的应用程序
应该仔细区分每个USER数据和每个会话
数据（例如，每个会话都有自己的购物车，但是
付费直至日期由同一用户的所有会话共享，并且
下载限制可能是每个用户，而不是每个会话。
顺便说一句，我认为对于很多应用程序，如果你必须阻止
重复登录，在检测到重复时，允许当前
登录并注销所有其他人使用相同的用户名。 （我不是
真的确定如何以防弹方式执行此操作，但如果您使用会话
处理程序将会话数据放入数据库而不是
默认临时文件，查找其他具有相同
用户名的会话变得更容易。他们将返回到
的登录页面下次尝试加载页面。）这可以防止合法用户出现许多问题，包括他们的系统崩溃/重新启动
然后无法重新进入直到烦人的
长时间超时。
我读过的解决方案似乎是使用另一个
变量来检查用户是否已经登录（简单
是或否）。很简单。我想要正常退出并删除
所有值都会删除它，然后删除cookie。但是，如果
浏览器只是关闭怎么办？
如果有另一个会话具有相同的用户名且时间戳
不是陈旧的，则您有重复登录。按指示行动。它可能是由最近关闭的浏览器造成的。在超时期限后，情况将自动纠正。
如果有另一个会话具有相同的用户名和时间戳
过时，这可能只是关闭浏览器。你应该用
来忽略陈旧时间戳的记录（好像它们不存在），
因为它们不能再使用了。
如果我了解一切如何运作，那么cookie将会在一段时间内自动删除。
如果用户登录，关闭浏览器并尝试再次登录，该怎么办？ ？
是否仍然存在登录已存在的值？或者我是
最有可能，是的，用户将被锁定。如果你使用时间戳是
，那么锁定只会在超时期限内。
以为我需要一个已经透明处理的问题的解决方案？
Gordon L. Burditt
Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
thx
(note: I sent an email about this earlier today, but I dont see it so Im
sending it again)
In article <Xn************************@216.168.3.44>, Theo wrote:Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
Instead of yes/no store the timestamp. And save that timestamp in the
session.
Everytime a user requests as page, compare the session timestamp with
the timestamp in the database.
If a new login has been done, the timestamp will be different.
--
Tim Van Wassenhove <http://www.timvw.info>
On Fri, 24 Sep 2004 22:45:53 -0000, Theo <in*****@noemail.com> wrote:
Question for the group
The authentication system for the site Im working on seems to function
properly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password. The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed? If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
thinking I need a solution to a problem that is already transparently
handled?
thx
(note: I sent an email about this earlier today, but I dont see it so Im
sending it again)
Right.. so are you using _SESSIONs or _COOKIEs? (or both?)
By default, both have "the same" lifespan.. for the duration of the
session. When the user closes the browser, the _SESSION or _COOKIE data
is removed (presuming you''re not using cookies and setting a specified
expiration date) thus I believe you''re looking for an answer to an
irrelevant question as when the user closes the browser, _all_ session
data will be destroyed, including the ''i_am_logged_in'' value.. whatever
you use to distinguish =)
HTH.
Regards,
Ian
--
Ian.H
digiServ Network
London, UK
http://digiserv.net/
>The authentication system for the site Im working on seems to functionproperly and all is good. A session keeps track of everything and a
cookie is used to accept or deny access... sounds as it should be I hope.
Then when all is done logging out destroys everything and the pages are
no longer accessable. Good so far.
But two things come to mind: one is preventing multiple logins of the
user/password.
Why? What problem are you trying to solve here?
If the intent is to prevent the sharing of pay site logins, you''re
trading one problem for another (denial of access by the legitimate
user). Of course, the site operator might like this problem, as
it costs less in bandwidth. But he might lose customers and his
site might get a bad reputation.
If the intent is some kind of security for abandoned sessions or
computers left unattended, put a timestamp in the session. Update
the timestamp to the current time on each successful page load (this
part comes after the logged-in check). On each page, the logged-in
check should include checking that the timestamp is not "too old"
(whatever value you decide for that). If it is (or the login is
otherwise invalid, say, the membership expired), destroy the session
and redirect to the login page. This should take care of "abandoned
sessions": any sessions older than the timeout aren''t any good any
more and they get destroyed if anyone attempts to use them. You
should also have an occasional cleanup process that deletes old
sessions which nobody attempted to use after they were abandoned
(mostly to reclaim disk space). Oh, yes, DON''T count on browsers
to delete a cookie at the appropriate time. Some desktops have
clocks that, well, suck, and may be years off. Also, sniffed cookies
may be resurrected on another computer somewhere, with a tricked-up
browser that doesn''t behave like you expect.
Your definition of "too old" should take into account what users
are doing with the pages: if it takes an average user 15 minutes
to fill in ONE form or compose message text, chances are a timeout
of 20 minutes is too short.
If the intent is some kind of assumption that if there are duplicate
logins, one MUST be an unauthorized cracker or will screw up your
application, well, that assumption is often false. It''s not that
uncommon for me to have several browsers running on several computers
viewing the same site all on the same monitor. Your application
should distinguish carefully between per-USER data and per-SESSION
data (for example, each session has its own shopping cart, but the
paid-until date is shared by all sessions for the same user, and
the download limit is probably per-user, not per-session).
Incidentally, I think for many applications, if you must prevent
duplicate logins, on detection of a duplicate, allow the current
login and log out ALL THE OTHERS using the same username. (I''m not
real sure how to do this in a bulletproof way, but if you use session
handlers to put the session data in a database rather than the
default temporary files, finding other sessions with the same
username becomes easier. They''d go back to the login page on the
next attempt to load a page.) This prevents legitimate users from
having a number of problems including having their system crash/reboot
and then not being able to get back in until after an annoyingly
long timeout.
The solution from what Ive read seems to be using another
variable to check whether or not the user is already logged in (a simple
yes or no). Simple enough. I imagine logging out normally and deleting
all values removes this and then the cookie is deleted. But, what if the
browser is simply closed?
If there is another session with the same username AND the timestamp
is not stale, you have a duplicate login. Act accordingly. It
MIGHT be caused by a recently-closed browser. The situation will
correct itself after the timeout period.
If there is another session with the same username and the timestamp
is stale, this might be a case of just closing the browser. You ought
to ignore records with stale timestamps (as though they don''t exist),
as they can''t be used any more.
If I understand how everything works the cookie
will still be there for a set period until its removed automatically.
What if the user logs in, closes the browser, and tries to log in again?
Is the value saying the login already exists still there? Or am I
Most likely, YES, and the user will be locked out. If you are
using timestamps, the lockout will only be for the timeout period.
thinking I need a solution to a problem that is already transparently
handled?
Gordon L. Burditt
这篇关于会话和关闭浏览器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
