Drcom账户管理Server端解说

https://www.github.com/xiyouMc

首先今天要讲的是针对Drcom查询账户URL的解析和抓取数据。

   Drcom是大学生宿舍上网普遍使用的联网client，然而对于自己账号的信息查询和改动password等都没有提供一个合理的方式去解决，因此小弟尝试去编写实现移动端的 app以方便大学生针对自己drcom账户的管理。

架构由来和设计

       刚開始我是想直接基于某公司开发的b/s架构去实现client，然而当我去了解该B/S架构的时候才发现去实现C和B/S的架构不合理。为什么不合理呢？由于该B/S架构中当然使用到session机制和图片验证机制等等的，要在移动端进行编写实在是工作量和逻辑有些复杂。而且编写出来的client势必会有比較大的累赘。

因此我放下当前的工作，细致思索一个合理的解决这样的累赘的方法。 最后我想到了自己去实现server，让这个server端进行业务逻辑的处理。

    当然我实现server第一想到是通过servlet去实现（由于小弟眼下就仅仅会使用jsp/servlet去实现server端）。这样的架构的设计，个人取了一个名字，不知道是不是已经有了这个架构设计--------------css架构。 一个client，两个server端。

这里的两个server端。相信不用说大家也知道是什么了。没错，就是我的server和某公司的server。（ps:全部的全部，还是由于小弟不才，搞不到那个数据库，仅仅能用这样的“卑鄙”的手段去解决这个问题）

核心逻辑

  首先大家要了解fiddler这个抓包工具。

在这个项目開始之前。我先通过fiddler抓取并大概了解到该B/S架构的业务逻辑。

   1、对password进行加密的方式。

         我通过fiddler进行抓包，发现登录的http请求中会对password进行加密，然后每次加密后的password都不一样并且是32位的一个字符串。当时我的第一反应就是该加密方式可能是通过MD5进行加密。

然而令我困惑的是该browser端是怎样对password进行加密的。并且是怎样做到每次加密后的password不一样。之后我去看该html的源代码。发现了一个重要的信息。就是这个html中嵌入了javascript。而这个javascript标签却不是固定的，是动态的。

<script>
function IsDigit(cCheck)
	{
	return ((‘0‘<=cCheck) && (cCheck<=‘9‘));
	}

function IsAlpha(cCheck)
	{
         return (((‘a‘<=cCheck) && (cCheck<=‘z‘)) ||(cCheck!=‘_‘) || ((‘A‘<=cCheck) && (cCheck<=‘Z‘)))
	}

function IsaNull(cCheck)
	{
	return(cCheck != " ")
	}

function checkform()
{
        var cCheck;
        var nIndex;
	strUserID = document.LOGIN.name.value;
	if (strUserID == "")
		{
		alert("请输入用户帐号");
		document.LOGIN.name.focus();
		return false;
		}

	for (nIndex=0; nIndex<strUserID.length; nIndex++)
		{
                cCheck = strUserID.charAt(nIndex);
                if (!(IsDigit(cCheck) || IsAlpha(cCheck) || cCheck==‘-‘ || cCheck==‘_‘ || cCheck==‘.‘))
			{
			alert("帐号名仅仅能使用字母、数字以及-、_和.，而且不能使用中文");
                        document.LOGIN.providername.focus();
			return false;
			};
        }
	strUserID = document.LOGIN.serial.value;
    queryNum ="null";

	if (strUserID == "")
		{
		alert("请输入4位随机码");
		document.LOGIN.serial.focus();
		return false;
		}

  

    Sessionid ="84b3613e39876c78a177bf0555a4da93";
    LOGIN.password.value = LOGIN.password.value + Sessionid;
    LOGIN.password.value = calcMD5(LOGIN.password.value);
    LOGIN.submit();


}

</script>

加密方式就是上面显示的。

之后我首先抓包获取一个登录请求的參数中加密后的password，然后获取该sessionid。最后通过自己的md5加密算法对正确的password进行加密获取一个32位加密后的字符串。通过匹配，我发现该password和http请求中的password參数全然符合。之后我就确定了我的加密方式和该browser端的加密方式全然一样。

每次请求主页的时候，对该html页面进行解析。获取sessionid然后登陆的时候通过md5进行加密。这样就攻克了对password进行加密的工作。  

   2、该逻辑中使用到了session。

        session这个技术也是我这次刚接触到的。

        session:

在编程里是会话的意思
Session 对象存储特定用户会话所需的信息。
这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。


当用户请求来自应用程序的 Web 页时。假设该用户还没有会话，则 Web server将自己主动创建一个 Session 对象。当会话过期或被放弃后，server将终止该会话。

Session 对象最常见的一个使用方法就是存储用户的首选项。比如。假设用户指明不喜欢查看图形，就能够将该信息存储在 Session 对象中。
有关使用 Session 对象的具体信息，请參阅“ASP 应用程序”部分的“管理会话”。

注意 会话状态仅在支持 cookie 的浏览器中保留。

      针对该browser端，当中使用到了session和图片验证。之后我查询资料。并自行去实现图片验证登录，或者说是session登录验证。实现原理: 第一次请求服务端会产生一个session放在<set-cookies>中response给浏览器，获取图片的时候必须将该session作为cookies发送给服务端。这个时候服务端做的工作就是首先随机产生一个四位数然后将该数字作为值设置给session。也就是将session和随机码进行绑定，这样做的目的是在登录的时候服务端能够推断该四位随机数是否正确。

  3、重定向。

       重定向状态码也就是3xx.  针对这个架构。进行http请求的时候假设session和图片验证都正确的话，状态码会是302，这个问题。当时也纠结了我好长时间。  由于在代码中假设不推断状态码的话。请求一直都是一个页面。 当时我一直以为是session的原因。 302真是个奇妙的状态码。哈哈。回到正文。假设账号 password session 和图片验证都正确的话，会进行重定向。包头会有一个location，这个location就是要跳转的页面.

 针对该架构要注意的一点就是每个http请求都必须在请求头添加cookie键，值就是第一次产生的session。

附加:

client的编写逻辑

     主界面首先对获取图片的api进行请求，该接口会返回session，然后保存在后面的请求中都加上session这个參数。

源代码：

https://github.com/xiyouMc/DrcomClient

https://github.com/xiyouMc/DrcomServer

Thanks for your reading,by Mc. 


希望大家能够follow我的Github.以后相互交流技术。感谢你们的star。