导读：讲到天翼，大家应该都熟悉，有朋友问天翼useradmin忘记密码，另外，还有人想问useradmin天翼初始密码，这到底怎么回事呢？其实useradmin天翼初始密码呢，下面是小编推荐给大家的useradmin天翼初始密码，一起来看看吧。
 

 
useradmin天翼初始密码
 
您好，电信宽带猫的默认登录帐号是useradmin，登录密码是admin
 
nE7jA%5m 这个是中国电信的超级密码，你可以输入帐号然后用这个试下，只要是电信的就行
 
天翼宽带家庭网关用户：useradmin 请问密码是什么
 
一般情况下，密码都是admin。
 
如果不正确的话，可以按猫后的复位键恢复出厂设置。
 
另外在猫的背面也有密码。
 
路由器的用户名useradmin是什么意思，密码怎么输，我的网路是电信的，路由器是TP-LINK的
 
1、TP-link路由器默认用户名通常是admin，它的默认密码也是admin,如果你的用户名是useradmin或者虽然用户名是admin但输入密码admin后没反应，说明密码已经被修改过
 
2、如果密码被修改过，那么必须用修改后的用户名和密码都能登录，如果密码忘记了，那么只能重置恢复默认用户名和密码，重置的方法是：路由器通电后用一支牙签按住reset钮5秒以上即恢复到出厂设置。
 
点击↓官方网址获取更多服务 客服324为你解答。
 
天翼宽带家庭网关用户：useradmin 请问密码是什么？
 
一般情况下，密码都是admin。
 
如果不正确的话，可以按猫后的复位键恢复出厂设置。
 
另外在猫的背面也有密码。
 
天翼宽带用户名是useradmin,登录密码路由器上没有，请问是多少？
 
你说的是装宽带自带的路由猫的密码还是自己路由器的密码，如果是路由猫的话，
 

 
背面会有默认终端配置账号和密码，一般密码是6位英文字母，如果是你自己的路由器那么得看你是什么品牌的路由器，一般路由器的密码都是：admin。
 
路由器出现useradmin密码是什么？
 
根据您的描述:路由器默认用户名通常是admin，它的默认密码也是admin。
 
登陆192.168.1.1后出现天翼宽带useradmin，请问输入什么密码？
 
终端设备密码，在猫上有写的。
 
中国电信的天翼宽带“useradmin”的密码是什么？
 
一般情况下，密码都是ADMIN，如果不正确的话，可以按猫后的复位键恢复出厂设置，另外在猫的背面也有密码的。
 
天翼宽带家庭网关的用户名和密码是多少？
 
路由器背面有账号密码的，如果还不行就恢复出厂设置进行修改，
 
『青青星座网』原创文章，未经允许不得转载

__user表示是一个用户空间的指针，所以kernel不可能直接使用。__user宏简单告诉编译器（通过 noderef）不应该解除这个指针的引用（因为在当前地址空间中它是没有意义的）。
 #ifdef __CHECKER__
 # define __user __attribute__((noderef, address_space(1)))
 # define __kernel /* default address space */
 #else
 # define __user
 # define __kernel
 #endif
 
 
 noderef告诉编译器，不应该解除该指针的引用，因为在当前地址空间中它是没有意义的。
 
 
 这里的CHECKER表示是否使用了Sprase（就是一种静态分析工具，用来分析内核源码中的BUG）。是不是想研究一下了？呵呵。可以参见http://sparse.wiki.kernel.org/index.php/Main_Page
 
 
 所以对于这种变量，在kernel中使用要用到copy_to_user和copy_from_user。

之前写过一篇单设备登录的小文章，写的不详细，所以在原来的基础上进行了修改。另外也加入了在修复此次bug的感悟与总结。希望自己能不断反思与进步，也希望能和大家互相讨论学习。
 
一、什么是单设备登录？
 
1.单设备登录概念   
 
    以QQ登录为例，当使用不同的手机（目前QQ支持pad与电脑、手机同时在线，但是相同类型的终端是不可以的）登录同一个QQ账号的时候，后登录的终端会把之前登录的终端给踢下线。也就是说同一账号不能在两台设备上同时登录使用。
 
2.单设备登录与单点登录的区别
 
    单点登录（SSO），英文解释为Single  Sign  On。单点登录是在一家公司的服务不断增加的环境下，用户面临输入多次账户密码的窘境。例如，要登录豆瓣FM、豆瓣读书、豆瓣电影、豆瓣日记......多种豆瓣相关的服务，每次如果都需要输入一次账号密码，岂不是用户要疯掉？并且也存在安全问题。此时就引入了单点登录，也就是说多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。与单设备登录其实并没有多大关系。
 
二、单设备登录实现原理
 
1.Token标识
 
数据库中保存有Token与User相关联的信息：
 
关键信息：user_code ---> token_id --->old_token_id，注：oldTokenId存三个tokenId。
 
2.tokenCache缓存
 
缓存userCode ---> token_id 与old_token_id ---> token_id；缓存时效可配置，目前为5分钟。
 
3.机制
 
前提条件：
 
    用户登录完成后，每次发送的请求需要携带登录成功后所返回的tokenId与当前设备号，并且同一台设备的设备号不能发生更改。
 
具体实现的两个关键点：
 
 
 
A.登录操作：
 
    用户登录会更新userToken信息，主要是更新tokenId与oldTokenId字段。另外也需要更新user的设备号信息，并把此次的设备号信息以userCode ---> DSN的形式存入deviceCache缓存中。
 
    在更新数tokenId时，会把此次登录的tokenId以userCode ---> tokenId存入tokenCache缓存中。在缓存有效期内，多次登录操作不再更新数据库tokenId字段。
 
B.UserLoginFilter过滤操作
 
    根据过滤到的请求的session中是否存在user信息分为两部分操作：
 
    1) user信息为空，需要判断用户是否满足长登录要求。
 
    根据此次请求所携带的tokenId从tokenCache中获取最新的newTokenId，若为空则生成一个并存入该缓存中，使得并发的请求都能得到同一个newTokenId。当然这部分代码放在了同步块当中。
 
    然后通过请求中所携带的tokenId查询对应的用户，若对应用户不存在，则用户需要重新登录。反之则直接登录此用户，并把之前生成的newTokenId更新到数据库UserToken表中。以备后续请求（携带newTokenId）能够在通过tokenId在数据库中获取user对象。
 
    2) user信息存在，判断是否存在多设备登录的情况，需要实现单设备登录的需求。根据此次请求所携带的设备号与缓存中的设备号（每次登录后会把当前设备号存入缓存，时效为30分钟[ 目前认为30分钟时间太短 ]）进行对比，不一致则通知当前请求的设备被其他设备踢下线。若设备号的缓存时效，则从数据库中查询用户的设备号进行对比。
 
    至此，功能基本完成。
 
三、单设备登录遇到的问题
 
1.并发问题。
 
    若A用户同时发送多个请求，req1,req2,req3...他们做携带的tokenId一致。并且都执行到过滤器，由于并发的不确定性，无法保证数据库数据与缓存中的数据的一致性。即：req1判断当前请求中user为空，进行长登录操作，需要根据tokenId查询对应的user，完毕后会进行登录操作，登录又会更新缓存与数据库中的tokenId。若req1已经更新了数据库与缓存，此时req2也判断user为空需要进行长登录操作，也需要通过tokenId查询对应的用户，而此时req1已经更新了数据库，req2再通过该tokenId就会查询不到user，则该请求就会通知客户端需要重新登录的信息。就无法完成长登录的功能。
 
2.集群问题
 
    在修复长登录与单设备登录问题的测试过程中，总是出现在本地测试一切正常，一旦把代码打包到178环境就会有各种各样的问题出现。原因就是178环境是集群部署，另一台服务器是165，打包时并没有考虑到165环境，并且ehCache也没有实现集群配置。导致代码在本地正常，放到178就有问题。
 
    这一度迫使我们加班到很晚也依然没有找到问题所在，因为静态代码分析各种情况都已经考虑的十分周全，理论上是不可能出现那些情况的。这也是当时最最最头疼的问题（虽然是低级错误）。
 
四、另一种实现思路
 
1.长登录
 
    针对并发，每当App启动的时候，发送请求checkToken.app，去校验该用户的token是否还是有效的。需要与缓存中的token进行比对，若有效就更新数据库token，并返回更新后的token，同时在缓存中存入该token值。若无效，则根据tokenId查询token对象。如果可以查询到，则更新token并返回新token，同时更新缓存数据。若查询为空，则当前用户的发送请求的token已经失效，需要其重新登录。
 
    登录操作，需要更新用户token并返回最新token给客户端，并同时刷新缓存记录。
 
    假如该用户此次校验token通过，则后续发送的请求都要携带最新的token值来进行访问。Filter中需要校验该token是否有效即可（与缓存中比对）。若失效，则需要用户重新登录。
 
    这种做法比较关键的问题是缓存有效时长。如果只设置5分钟，用户也一直用app操作的情况下，当缓存失效，就会被迫重新登录。所以把缓存失效设置为24h。在这24h内，用户的app关闭或切换到后台较长时间，就会触发checkToken机制，重新获取新的token值。
 
2.单设备登录
 
    在以上实现机制的前提下，单设备登录自然就实现了。A账户在A设备上登录，同时B设备也登陆A账户。此时会更新用户的token并刷新缓存，A用户在访问时，Filter会校验token值，此时A设备中的token已经是失效的、不是最新的token值，就会被强制重新登录。反之亦然。
 
3.存在问题
 
    客户端无法控制每次重新加载App时都要去发送checkToken.app的接口，因此无法保证token的正确性。但我认为这种方式最合理有效。
 
五、反思与收获
 
1.反思
 
     我认为导致此次问题的最大原因就是考虑问题不周全与个人技能不足。
 
    人非圣贤孰能无过，对于第一个问题是无法完全解决的，但是可以尽力避免。过不仅仅是过失，还有看待问题的个人局限性，无法把问题的方方面面都考虑其中。对于自己来说，就是对并发与框架的熟悉度不够。没有把并发问题纳入代码设计中来，也就直接导致了今天这个问题。痛定思痛，应该在今后的工作与学习中，更加努力与更加勤奋！
 
2.收获
 
    此次收获还是十分丰富的。
 
    首先对并发有了新的认识。考虑并发就跟排列组合一样，各种各样的问题与可能性都要考虑到。特别是并发数增多，可能性更是指数级别的增长。以及对synchronized与violate的使用也有了自己的看法。对于接触并发很少的我是一个提高自我恰好的时机。再有就是对静态代码的逻辑分析能力，由于并发情况多种多样，需要自己设想各种情况，然后按照代码逻辑走下去，并考虑各种变量的值与当时服务器缓存情况。
 
    学如逆水行舟，不进则退。Learn playing, Play learning !

首先我觉得很有必要说明一下单设备登录与单点登录的含义。我在网上搜索此类消息发现很多文章都误解了这两者的意思。
 
**单点登录：**英文Single Sign On，根据英文含义不难理解，即：单一标记（单点）登录。就是说，我只需要登录一次。例如：QQ，我在QQ空间登录一次，我可以去访问QQ产品的其他服务：QQ邮箱、腾讯新闻等，都能保证你的账户保持登录状态。
 
**单设备登录：**就是只能在一个设备上登录，若同时在其他设备登录，先前登录的用户会被提醒：该账户在其他设备登录。例如qq，小米手机登录中，同时拿华为手机登录该账户，小米手机的账户会被挤下线。
 
说清楚了这两者的区别，那来讲下我的思路吧。第一次做这个功能，并且是做的Java web端的功能。还请各位大牛指点一二。小弟在此多谢了！
 
思路1：
 1.添加Session监听器，把服务器产生的session，以sessionId与session作为映射关系保存在Map中。
 2.保存用户与对应的session，以userCode与sessionId为映射关系保存在服务器缓存(Cache)中。
 3.在用户登录时，根据用户code获取sessionId。
 A：如果sessionId为空，则说明该用户还没有登录过，把此次登录的userCode与对应的sessionId保存到缓存中；并存入一个表示信息，isInvalid=0。表明此session有效；
 B：否则，为第二次登录。然后把缓存中的上次登录保存的userCode及其对应的sessionId删除；再把此次登录状态信息保存到缓存中；
 C：通过sessionId查询到上次登录的session，改变session中isInvalid状态为1，表明失效状态。
 D：最后，过滤器中从session里面取出isInvalid字段，判断其是否有效。若有效则继续其他过滤；否则把isInvalid字段修改为2,表明这个session已经被处理过。然后通过转发，把此次请求转发给其他控制器处理。
 
当我按照上述思路做完代码，进行测试的时候。竟然成功了，还是很激动的。但是不久后发现了一个**问题：**在我在A端登录账号后，然后再B端登录。接下来我不在进行A端的账户操作，等到其session失效，我再进行操作，这个时候，先前的session中所存放的isInvalid标识已经不存在了。这个时候，过滤器是检测不到信息的。所以会被后续的过滤进行保持登录的代码所覆盖，然后重新登录进去。这个时候A端与B端同时操作是互相不影响的。
 
思路2：
 
 
 
借鉴网友：在用户表那儿添加多一个INT列，这个专门放随机数，每登陆一次，随机数就变化一次，并将随机数放在cookies或session中，每每读取和数据库的作对比，如果发现不对，就说明，别人己在另一个地方登陆了，这时就弹出“己在另一地方登陆”，然后关闭窗口，这样就行了。
 
 
这个思路我觉得可行，但是会频繁查询数据库，每一次请求都需要校验，然后就需要去与数据库里面的值进行对比校验。这个我觉得是可以避免的。
 
**我的想法：**我觉得可以把用户与对应的随机码存放在服务器缓存中（userCode==>UUID），并且把UUID存入cookies里面，之后的请求就包含该UUID。第二次登录的时候，再往缓存中放入userCode与UUID。这样就会覆盖先前存放的数据。如此，第一个登录的用户，再携带它的UUID去访问时，过滤器就会拿该UUID与缓存中的UUID进行对比。如果不一致，则说明其他设备登录了该账户。就提醒这个用户账号在其他设备登录即可。
 
我觉得这个方案是可行的，并且不用频繁的去操作数据库了，应该性能方面会有所提升。