利用两层iframe跨主域获取json数据

数据消费者: http://consumer.net/page.htm 数据提供者: http://provider.net/json.htm 方案 1.提供端搞一个provider-proxy,用作消费端的iframe 2.provider-proxy请求提供端的数据。 由于同域,所以这次请求能够成功;但是请求的结果无法直接返回给作为父frame的消费端(parent.document.callback(data)),因为当父子frame不同域时,子frame的parent.document引用会被浏览器禁止。 3.消费端要搞一个consumer-proxy 4.consumer-proxy完成最后一步(一种非常取巧的做法)     a.provider-proxy拿到返回的数据结果后,生成一个iframe(或者重用),再调用 iframe.src="http://page.net/consumer-proxy?data=" + data; 这条语句使得consumer-proxy成为provider-proxy的iframe,同时它还把数据结果作为参数传给了consumer-proxy     b.consumer-proxy被加载后,则从参数中拿到data值,然后调用 parent.parent.document.callback(data);  而parent.parent就是消费端的大页面,就这样一搞,形成了数据回路。 那么,parent.parent.document为什么是一个合法的引用?       i. 首先,parent.parent是一个合法的引用,不管同不同源      ii. 其次,consumer-proxy的域是consumer.net, parent.parent的域也是consumer.net, 所以在consumer-proxy页面里引用parent.parent.document是合法的,不会违反同源策略。

利用iframe跨子域获取json数据:方案及注意事项

数据消费者所在子域: http://page.kentphp.net/ 数据提供者所在子域: http://text.kentphp.net/ 方案 提供端搞一个proxy,用作消费端的iframe <!–提供端:http://text.kentphp.net/proxy.htm –> <!- Hey, I’m proxy–> <!–消费端:http://page.kentphp.net/page.htm–> <iframe id="proxy" src="http://text.kentphp.net/proxy.htm"> </iframe> <script> document.domain="kentphp.net"; </script> 提供端proxy和消费端设置同样的document.domain <!–提供端:http://text.kentphp.net/proxy.htm –> <script> document.domain ="kentphp.net"; </script> <!–消费端:http://page.kentphp.net/page.htm–> <script> document.domain ="kentphp.net"; </script> 消费端通过proxy发起ajax请求,但使用自己的回调函数 <!–消费端:http://page.kentphp.net/page.htm–> <script> var iframe=document.getElementById(‘proxy’); var iJs=iframe.contentWindow.$; //iframe的JS根句柄;这里之所以能拿到这个句柄,是因为本页面和proxy页面都将domain显式设置成了同一个值 iJs.get("http://text.kentphp.net/dummyJson.htm",function(data){//这里的ajax get之所以能成功,是因为proxy的原生domain和dummyJson.htm的domain相同。 alert(data); }); </script> 这样就可以了。  说明,及注意事项 1. iframe页面能把’$’函数暴露给父页面,是因为两者的domain都是kentphp.net; iframe页面能顺利请求dummyJson.htm, 是因为两者的domain都是text.kentphp.net.  也就是说, iframe有两个domain name, 一个是原生的text.kentphp.net, …

利用iframe跨子域获取json数据:方案及注意事项 Read More »

android的进程倒底有没有退出?

android强调activity, 弱化了进程的概念。 按返回键退出activity时,除非显式在onDestroy()方法里使用System.exit(0),否则进程并不会退出,而是驻留在后台 (未必会出现在运行列表里)。 当你重新进入某个程序时,系统把后台程序直接推到前台,减少重建进程的开销,让用户获得比较快的启动体验。 可是如果程序驻留过多,内存会不会浪费甚至耗尽?  系统看内存有点紧张时,会自动杀掉一些里程;当然系统在这方面做的并不完美,驻留程序多了,手机还是会卡的。作为开发者,最好还是提供显式退出功能。

Android与OAuth: 用户在哪授权? (还没研究透)

OAuth之所以适合三方协作,就是因为用户不需要在第三方系统里直接用户名/密码;而是在OPEN ID提供者的系统里输入,然后再跳到第三方系统。 在B/S环境下,OAuth通过浏览器跳来跳去完成这种事;但Android这种C/S环境下,怎么搞? 我初略地做了些研究,得出的结论是大概有几种方式: 1. 新浪微博的OAUTH2: 第三方应用通过web view或者什么方式弹出浏览器,让用户在一个很小的新浪授权页中输入用户名/密码,然后回到第三方应用。 2. 新浪微博的SSO: 第三方应用通过Intent启动本机中安装的微博Android应用,选择用户后回到第三方应用。 严格地说,这可能已经不是OAUTH了。 (我写这篇文章时weibo客户端的SDK没有源码,所以我无法深入研究,给出答案) 3. Google的AccoutManager.getAuth(): 第三方应用调用AccountManager.getAuth()时,Android会 启动AccountManager自带的一个Activity让用户决定是否授权( 原文:During the AccountManager.getAuthToken() call the AccountManager will check if your application has been authorized to access the Tasks API. If your application has not yet been authorized an Activity is started by the AccountManager which displays an authorization …

Android与OAuth: 用户在哪授权? (还没研究透) Read More »

OAuth的核心作用

OAuth的核心作用: 用户不必在第三方网站上输入OPEN ID及其密码,否则第三方网站可以把你的用户名、密码偷偷地保存起来。

Android开源项目研究: last.fm android的用户认证

概述 last.fm android的认证机制与cookie类似,但与cookie无关。 类似于OAUTH,它也有appKey/appSecret体系,以允许第三方开发者开发应用;然而,这个体系跟OAUTH没有任何关系,last.fm android这个APP也跟第三方开发者没有什么关系。 登录、认证流程 1. 用户输入用户名、密码 2. 客户端把用户名、密码经加密处理后传给服务端,服务端认证通过后,返回一段XML;客户端再把这个XML反序列化为一个JAVA对象:fm.last.api.Session. 这个对象包含userName和一个token(代码中称为sessionKey) 3. 客户端会把对象中的 userName和sessionKey存入到settings中 (SharedPreference) 4. 同时还会把这个Session对象作为一个全局变量放在内存中,相当于setting中所存session信息的缓存 5. 后续的访问中,如果客户端需要表明身份,则会传入sessionKey; 服务端会通过sessionKey来判断该请求是否代表合法的用户。 整个过程类似于服务端返回一个cookie, 客户端在后续请求中发出cookie . 如何记住登录 启动后,在LastFMApplication这个activity的onCreate()中会 去settings中取出已登录的userName和sessionKey ,然后封装出Session对象,作为全局变量放到内存里;接下来直接进入LastFm Activity或Profile Activity,整个过程并没有网络交互。 服务端并没有校验,是不是有安全漏洞? 如果我在首次登录后,把用户名换成另一个人的,就不是可以这个人的身份操作本APP? 答案是:你只能成功进入LastFm和Profile,但无法继续以受害者的身份进行操作;因为在后续的业务数据访问请求中,还是要附带上sessionKey,服务端会根据sessionKey找出你的真实身份。 登出时的行为 登出时会把内存中的Session全局变量置为NULL,并去settings中把userName和sessionKey清除。 这就类似于浏览器中的cookie清除 . 具体使用的通信协议 1.走的是http , 直接用HttpURLConnection;  API叫 Parser.getItem(url, params, …) 2.用了https,但不校验任何证书(方法名:trustAllHosts()) 附:加密的细节信息 String md5Password = MD5.getInstance().hash(pass); //一次哈希 String authToken = MD5.getInstance().hash(user …

Android开源项目研究: last.fm android的用户认证 Read More »

可用来观摩学习的开源安卓应用

http://blog.interstellr.com/post/39321551640/14-great-android-apps-that-are-also-open-source https://en.wikipedia.org/wiki/List_of_free_and_open-source_Android_applications https://github.com/c99koder/lastfm-android https://github.com/cattong/YiBo

大屏、小屏、横屏与无线UI布局的关系

UI的布局只是指界面组件之间的相对位置,而跟组件的大小及长宽比例无关。 对于普通的联系人界面,把手机横过来,你会看到组件变得扁平了,但这时布局没有变。 对于小屏(phone)变大屏(pad),如果程序没做特殊设置的话,布局也不会变。 如果两个组件在竖屏是垂直排列,在横屏时变成水平排列,这才叫自适应布局。 这种东西一般要写程序的人做好支持,比如在安卓里写两个layout文件,res/layout/*.xml代表竖屏的布局,res/layout-land/*.xml代表横屏的布局。 大小屏与此类似,如果要搞自适应布局,在安卓里也要写多个布局文件。

32位机器中long, double的读写不是原子的

在32位机器中,由于long, double数据较长,跨多个地址;导致这个long, double的读写不是原子的。 所以,对long, double的读写操作,在必须情况理应该加锁。 在64位机上,理论上long,double是原子的;但由于指针压缩技术,long,double等仍可能跨地址存储,所以对它们的读写操作可能仍不是原子的。