检测 CTRL-N 或用户何时打开新窗口的方法
我们如何检测用户何时打开新窗口。 用户已经通过身份验证,我们大量使用会话。
我们试图避免 Ctrl+N javascript 挂钩,但也许这是一个选择。
我假设请求是完全相同的 URL...使用 Ctrl+N?
How can we detect when a user opens a new window. The user is already authenticated and we make heavy use of sessions.
We were trying to avoid Ctrl+N javascript hooks but maybe that is an option.
I am assuming the request is the exact same URL...with Ctrl+N?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
算了。 虽然理论上您可以尝试使用 Control 键修饰符捕获“n”的按键事件,但还有许多其他方法可以打开新窗口或选项卡,这些方法可能更有可能被使用,并且您将无法去抓。 文件 -> 新窗口/选项卡,中键单击或 Shift 单击链接,中键单击后退/前进按钮,右键单击在新窗口中打开,在新选项卡中打开书签,双击浏览器图标...
这本身应该不是问题。 我猜你的意思是你的应用程序在会话中转储了它不应该有的各种特定于页面的数据,现在你发现当你打开多个窗口时应用程序会中断? 好吧,同情和快乐的重写。
与此同时,您所能做的就是告诉用户“请不要尝试在同一应用程序上打开两个浏览器窗口”。 有一些潜在的方法可以让一个页面上的 JavaScript 注意到 JavaScript 同时在同一域中的另一个页面上运行,通常涉及使用 document.cookie 作为页面间通信管道。 但这也有点脆弱。
Forget it. Whilst you could in theory try to catch keypress events for ‘n’ with the Control key modifier, there are any number of other ways to open a new window or tab which may be more likely to be used, and you won't be able to catch. File->New Window/Tab, middle click or shift-click link, middle click back/forward buttons, right-click-open-in-new-window, open bookmark in new tab, double-click browser icon...
That shouldn't be a problem in itself. I guess what you mean is that your application is dumping all sorts of page-specific data in the session that it shouldn't have, and now you find the application breaks when you have more than one window open on it? Well, commiserations and happy rewriting.
In the meantime about all you can do is tell the user “please don't try to open two browser windows on the same application”. There are potential ways you can make JavaScript on one page notice that JavaScript is running on another page in the same domain at the same time, generally involving using document.cookie as a inter-page communications conduit. But that's also a bit fragile.
如果打开一个新窗口导致应用程序出现问题,那么您应该修复应用程序代码来处理它,而不是尝试应用不一致且不可靠的客户端“绷带”。 这是我的意见。
If opening a new window causes a problem in your application, then you should fix the application code to handle it instead of trying to apply an inconsistent and unreliable client-side "bandage". That's my opinion.
为什么?
而且无论如何你都无法检测到它。 用户不仅可以使用Ctrl+N打开新窗口,还可以使用文件->新窗口打开新窗口。
Why?
And anyway you can't detect it. User can open new window not only with Ctrl+N but also with File->New Window.
您可以将窗口计数放入会话中,并在
window.onload
上递增它,并在window.onunload
上递减它。想象一下,如果你用这个的话,我会发出咕噜声,用牙齿吸气,然后说“你比我更好,guvna”。
You could possibly put a window count into the session and increment it on
window.onload
and decrement it onwindow.onunload
.Imagine me tutting, sucking air through my teeth and going "better you than me, guvna" if you use that, though.
我为解决此问题所做的工作是,当用户进行身份验证时,在有效登录时设置窗口名称。
然后在母版页上进行 javascript 检查:
如果检查为真,则隐藏/删除页面的主要内容并显示一条消息,说明他们正在执行不受支持的操作。
当您的登录页面未绑定到母版页时,此方法有效。
如果您没有母版页,那么我建议您在所有页面上进行检查。
What I have done to solve this issue is when the user authenticates set the window name on valid login.
And then on the master page do a javascript check:
If the check is true then hide/remove the main content of the page and show a message stating they are doing something unsupported.
This works when your login page is not tied into the master page.
If you do not have a master page then I would suggest putting the check on all your pages.
是的,也不是,
如果控件具有焦点,您总是会看到它,否则事件将直接发送到浏览器,页面上的代码永远不会听到它。
根据我的经验,你不能劫持浏览器的快捷方式,你的里程可能会有所不同。 您可能知道它发生了,但浏览器会做它的事情(出于明显的原因)
在大多数浏览器中,Ctrl-N的效果是在以下位置打开一个新窗口与旧 URL 相同的 URL 并将其与相同的 sessionID 关联。
如果可能的话,最好的选择是修改后端代码并允许此类事情。 破坏浏览器的功能从来都不是一件好事。
Yes and no,
You'll always see it if a control has focus, else the event is sent directly to the browser and the code on the page never hear about it.
In my experience you can't hijack the browser's shortcut, your mileage may vary. You are likely to know it happened but the browser will do its thing (for obvious reason)
In most browsers, the effect of Ctrl-N is to open a new window at the same URL as the old one and associate it with the same sessionID.
Your best bet would be to modify the back end code if possible and allow for such things. Breaking the browser's feature is never a good thing.