BS客户端能否同时登陆多个用户

    我们都知道，BS架构的系统，为了维护客户端的状态，需要在服务端维护客户端的session。每次客户端请求的时候，浏览器会在请求报文的头信息里面带上sessionID传递给服务端，服务器收到请求之后比对sessionID就知道了是谁发过来的请求，继而继续提供服务。

   早期的浏览器，每次打开时候是新开一个窗口，窗口之间不一定是共享session的。所以每次在同一台机器上运行同一个浏览器，很有可能需要用户都登录一次。这样给客户端造成的困扰是需要重复登录。

    后来，浏览器进化了。大部分浏览器都做成像谷歌浏览器这种卡片式的浏览方式，当然也提供单独拆分成独立的窗口浏览方式，最重要的是session数据在各个窗口中是共享的。但是问题是，有时候想同时登录多个用户也不可能了，非要换一种浏览器。因为不同种类的浏览器之间的session是不共享的。(其实，客户端的维护session信息应该叫cookie，为了保持说的是同一个东西，这里暂时都叫session信息。)

    我看到有人在网上发帖求助，想设计出满足同时登录多个用户的需求。

    J2EE入门知识就涉及到了会话跟踪的两种模式，一种cookie，一种URL回写。这两种正好是上述两种模式的解决方案。基于cookie的方式就是直接读取应用服务器维护的session，URL回写是通过URL传递跟踪参数，来判断请求是否符合要求。

    讲了这么多，我想说，到底处于什么样考量，来判断如何使用上述的模式。

    下面我给出我自己的看法。
    网上的系统，我大致将它们分为两类。
    一类是论坛这种，每当点开一个连接，是打开一个新的窗口，或者是新的浏览页面的。当然也有在本身窗口里面跳转至新页面的。而且新打开页面的方式(ctrl+左键)和在原页面直接跳转后显示的页面完全一致。这种模式的，我觉得应该基于cookie的，即客户端不能同时登录多个用户的。
    另一类是类似于网银这种管理系统，页面采用iframe之类，只在当前页面框架内跳转的，就算用crtl+左键，打开的页面也是只是某个局部iframe的页面。这种我是建议允许多用户登录的，那么就要用到URL回写的。
    为什么？论坛这种对内容的关注更大，为的是传递更多的信息量，要优先提供顺畅的浏览方式，所以不用刻意要求用户的登录形式。但是对管理性质的平台，对客户登录的形式要求很高，甚至系统本身就是基于权限体系上设计的。那么用户登录的认证就要考虑周全一点。不要仅仅只做session上的维护，建议在应用上追加一个额外的类session的管理体系。
    sessionID的生成模式可以使用UUID。