Re: [Kimchi-devel] [PATCH V5 0/5] Switch to a traditional login flow

On 6/16/2014 4:23 PM, Zhou Zheng Sheng wrote: > on 2014/06/16 15:53, Yu Xin Huo wrote: >> On 6/16/2014 11:33 AM, Zhou Zheng Sheng wrote: >>> on 2014/06/13 18:47, Yu Xin Huo wrote: >>>> On 6/13/2014 6:07 PM, Zhou Zheng Sheng wrote: >>>>> on 2014/06/13 17:57, Yu Xin Huo wrote: >>>>>> On 6/13/2014 5:45 PM, Zhou Zheng Sheng wrote: >>>>>>> So your point is the proposed alternatives is uglier than the current >>>>>>> one, and the current one can be improved. >>>>>>> >>>>>>> Firstly from the JS accessing browser history link you gave me, I >>>>>>> don't >>>>>>> see anywhere it says it's unreliable. The solution doesn't need to >>>>>>> inspect the history, it just back needs to go back. >>>>>>> >>>>>>> Secondly you think "refresh.html" is uglier than cookie. It's >>>>>>> actually >>>>>>> not. A "refresh.html" only affects the login process, but the current >>>>>>> cookie solution affects all requests and responses that is not >>>>>>> related >>>>>>> to login. The current solution works, but it is far from works well, >>>>>>> and >>>>>>> if you want to improve it by suppress sending the previous page >>>>>>> cookie >>>>>>> in AJAX requests and response, more hacks would be added in both >>>>>>> front-end and back-end. This is not improving step by step. To >>>>>>> improve >>>>>>> step by step, the original direction should be correct and effective, >>>>>>> but this is not. >>>>>> Again, there will always cookie back and forth between browser and web >>>>>> container. It is handled automatically by browser and web container. >>>>>> What make you uncomfortable is that piece of code at server side to >>>>>> get >>>>>> previousPage. >>>>> Yes, but the previousPage cookie is unnecessary regardless if it's >>>>> handled automatically or not. The alternative solutions we discussed >>>>> can >>>>> avoid this unnecessary handling, and restrict the login handling logic >>>>> only to a small region of code and runtime process. >>>> there are 2 alternative solutions you proposed: >>>> >>>> 1. brower history >>>> -- unreliable as I replied. >>> 1. You are correct >>> >>>> 2. internal redirect >>>> -- 1. make browser url mismatch its content, it is >>>> desirable to make browser url truly address it intended content. >>>> 2. after login, server response back a refresh.html >>>> with javascript to reload browser, this refresh.html need to be pasted >>>> to browser to get that javascript to run. >>>> user will definitely perceive this page switch, >>>> make it a bad experience. >>>> 3. Compare with a single cookie attribute, there >>>> are >>>> must more side effects. >>> 2. There are plenty of ways to improve internal redirect method and >>> eliminate the need for "refresh.html". >>> >>> Option 2.1. Upon unauthenticated access, back-end internal redirects to >>> "login.html". The POST action of the form send the current page URI to >>> the back-end as well, then after the /login URI handler authenticates >>> the user, it fetches the "Referer" header of the request, and this >>> header contains the original page URL, then back-ends uses internal >>> redirect or HTTP 3xx redirect to present the original page content. >> "Referer" does not work. Please google search or try it yourself. > I tried it myself before I sent the previous mail, it works. The problem > is that intermediate proxy may change it, or the user can configure > firefox not sending it. It's not reliable, but it can served as the last > means to get the related page. Checked all types of requests, "referer" is always below in my env. If "referer" can work, I truly like it very much, that will save us a lot of complexity, can you paste a screen-shot of your env?

> >>> Option 2.2. Upon unauthenticated access, back-end internal redirects to >>> "login.html". The form in the "login.html" contains a hidden input >>> indicating the current URI. Then the JS in "login.html" fills this >>> hidden input upon successfully loading the page. So the POST action of >>> the form send the current page URI to the back-end as well, then after >>> the /login URI handler authenticates the user, it uses internal or HTTP >>> 3xx redirect to lead the processing flow back to the original URI. >> If the first time I try to access kimchi with >> "https://xxx.xxx.xxx.xxx:8001/login.html", what will happen? > There is nohttps://xxx.xxx.xxx.xxx:8001/login.html, it is only served > through internal redirect. The user can not directly access it. For web resources at server side, static, dynamic, protected, unprotected, there will always be a url addressable way to load it. For your design, it completely relies on browser url which is quite easy for user to input anything. For fuzzing security testing or robustness testing, any malformed url maybe tried to check server response. If user does input below, for your option 2.2, it will be a dead loop that user will always see login page. Tester will be quite happy to found it. "https://xxx.xxx.xxx.xxx:8001/login.html"

> >>> Option 2.3. Upon unauthenticated access, back-end internal redirects to >>> "login.html". "login.html" does not use traditional HTTP POST form, >>> instead, it uses /login API call to login using AJAX invocation, upon >>> successful login, "login.html" refreshes the page. >> how to differentiate first time login and session timeout? > Before internal redirection, back-end can check if it is first time > login or timeout, and sets an variable/title/label in the dynamic > rendered "login.html". I do not think there is a way to differentiate "user first time login" and "session timeout" by internal redirect. Can you clarity?

> >>> Actually "softlayer.com" is using some means of internal redirection to >>> guide user to the previous page. You can try to open the following links. >>> https://control.softlayer.com/account/invoices >>> https://control.softlayer.com/account/orders >>> You'll notice it returns a plain login page, after login, it triggers a >>> refresh that the user doesn't notice at all. > What do you think of softlayer.com ? We have designed a complete, end to end "login/logout/user, pass wrong/session timeout/preserve meaningful user context" experience. And figured out a technical solution to support it. If you do see any better user experience that softlayer delivered than our current design. Feel free to point out.

> >>> The page switch only happens in login process. Though you state cookie >>> approach as "single cookie attribute", but it gets transferred in every >>> request and response even the AJAX ones. It's obvious which is more >>> evil. There is also an inevitable bug in cookie approach. Say the user >>> opens two firefox tabs, one is for VMs, the other is for StoragePool. >>> Once the session is expired, and the user login in VMs, it may lead the >>> user to StoragePools if StoragePools happens to be opened after VMs. >> Quite easy to be solved, I believe there will be an event notification >> when switching tab. > The event notification is in the front-end, how do you send it to back-end? front end can also set cookie.

> >>> Moreover, I didn't see any investigation on how other WEB sites does >>> this. Though this is not my task, I just investigated softlayer to prove >>> my point. I suggest anyone who works on this firstly do some research on >>> the existing WEB sites and avoid re-inventing the wheel. >> Kimchi has its own problem and solution, others can be referenced, but >> not defined by them. > Yes. However I didn't said we should use the same mechanism as other > sites, but I said exactly we can refer them. The problem is that the > authors didn't referenced and analyzed other sites' solutions at all. At > least I didn't see them in the commit message, email, wiki or offline > discussion. Would you please tell me how many sites you referenced and > why none of the existing solutions can not be used? Or you can just send > me a link of you previous analysis. I do not believe all web sites use internal-redirect to do login, why you only reference a website that use internal-redirect? If I do want to reference others, I will list the top 10 web sites in this world and check how they implement it. Now, only hotmail is available, checked that it is not internal-redirect In an enterprise environment, all applications, systems need to be integrated to enable single access control, single sign on. The whole login process of all apps is delegated to a central access manager, how can internal-redirect work in this case?

> >>>>>> Both client javascript and web container can set cookie. >>>>>> the previsousPage can also be set with javascript in client side, >>>>>> each time user go to a new tab, there is a callback, in the callback, >>>>>> previousPage can be set into cookie. >>>>> But the previousPage cookie is still carried forth and back in normal >>>>> requests, which is absolute redundant information, not to mention the >>>>> troubles it causes when the user opens two firefox tabs accessing >>>>> different page of Kimchi. >>>> Cookie will always be sent back and forth regardless of our previousPage >>>> url. >>>> What trouble you mean when multiple browser tabs, please clarify. >>>> >>>>>>> on 2014/06/13 17:24, Yu Xin Huo wrote: >>>>>>>> First of all, what you are complaining about is a pretty, pretty >>>>>>>> small >>>>>>>> fraction of the overall login solution. >>>>>>>> For that fraction, the design is to back to the original url after >>>>>>>> user >>>>>>>> login from a session timeout. >>>>>>>> Shaohe's current implementation works well. what zhengsheng means is >>>>>>>> about how to improve it. >>>>>>>> >>>>>>>> On 6/13/2014 3:12 PM, Zhou Zheng Sheng wrote: >>>>>>>>> If I remembered correctly, Shao He, Yu Xin and me had several long >>>>>>>>> talks >>>>>>>>> on the login design. This solution is not the solution we >>>>>>>>> agreed, and >>>>>>>>> all of us thought that this solution is ugly and obviously >>>>>>>>> should be >>>>>>>>> improved. >>>>>>>> We have ever discussed several options, but we have not converged >>>>>>>> to a >>>>>>>> certain one. >>>>>>>> Let me continue to read to see what the 'ugly' you mean. >>>>>>>> >>>>>>>> This solution works very well, it can always be improved. >>>>>>>>> The problem is on how it redirects the user back to the previous >>>>>>>>> page >>>>>>>>> after login. In this patch, the back-end has to intercepts each >>>>>>>>> access >>>>>>>>> to any of the ".html" page, and sets >>>>>>>>> cookie['lastPage'] = current page URI, >>>>>>>>> and return it to front-end, then the front-end sends this cookie to >>>>>>>>> back-end in every query, including AJAX query. When the session >>>>>>>>> expires, >>>>>>>>> the back-end redirects the front-end to a login page, after login >>>>>>>>> successfully, the back-end gets cookie['lastPage'], at last, >>>>>>>>> redirect >>>>>>>>> the user to the last page. >>>>>>>>> >>>>>>>>> Just to implement returning to the previous page afte login, the >>>>>>>>> back-end has to intercept each '.html' access and sets cookie, and >>>>>>>>> the >>>>>>>>> front-end has to send the cookie in each request including AJAX >>>>>>>>> ones. >>>>>>>> Handling cookie back and forth is done by browser and web container. >>>>>>>> There will be always cookie, this is not an additional overhead. >>>>>>>> What shaohe does is only to get the current tab url. That is a quite >>>>>>>> small amount of code. >>>>>>>>> So in the last talk we agreed that a simpler and more effective >>>>>>>>> solution >>>>>>>>> should be used. We at least have two alternative solutions. >>>>>>>>> >>>>>>>>> 1. When session is expired, we redirect the user to login.html. >>>>>>>>> After >>>>>>>>> login successfully, the JS script in the front-end asks the >>>>>>>>> browser to >>>>>>>>> go back to the previous page. Since the browser keeps a stack of >>>>>>>>> page >>>>>>>>> histories, it should be easy to do this. >>>>>>>> This is server side redirect after form is submitted, at that time, >>>>>>>> client side has no code to run. >>>>>>>> Server side redirect browser directly to last page in login >>>>>>>> response, >>>>>>>> quite straight-forward. >>>>>>>> >>>>>>>> I do not think brower history will be a reliable solution. >>>>>>>> http://www.w3schools.com/js/js_window_history.asp >>>>>>>>> 2. When the back-end detects the session is expired or the user >>>>>>>>> hasn't >>>>>>>>> login yet, it uses internal redirect to present the "login.html". >>>>>>>>> From >>>>>>>>> the front-end point of view, an unauthenticated access to "GET >>>>>>>>> #tabs/vms.html" returns "login.html". After the user input his/her >>>>>>>>> password in the "login.html" and click "login", the back-end >>>>>>>>> receives >>>>>>>>> the request, if the password is correct, it returns a >>>>>>>>> "refresh.html". In >>>>>>>>> "refresh.html" there is actually a small JS code to ask the >>>>>>>>> browser to >>>>>>>>> refresh the page. Since we are using internal redirect all the >>>>>>>>> time, >>>>>>>>> the >>>>>>>>> page URI in the browser remains "#tabs/vms.html", so after the >>>>>>>>> login, >>>>>>>>> just refreshing the page would lead user to the real >>>>>>>>> "vms.html.tmpl". >>>>>>>>> >>>>>>>>> In the above two solutions, no ugly cookie is needed for each >>>>>>>>> request >>>>>>>>> and response, and the back-end doesn't have to intercept each >>>>>>>>> ".html" >>>>>>>>> access, but just has to intercept each unauthenticated access. >>>>>>>> internal redirect will make browser url mismatch with the content. >>>>>>>> the current design will always keep url address its intended >>>>>>>> content, >>>>>>>> this is a virtue over internal redirect we should pursue. >>>>>>>> >>>>>>>> The ugly cookie is removed, but introduced *a much uglier* >>>>>>>> "refresh.html" and code in that html. >>>>>>>> To me, it is much more complicated. >>>>>>>>> I don't know why Yu Xin and Shao He sent the to-be-abandoned >>>>>>>>> solution >>>>>>>>> again to the mailing list. Patches were sent on 20:00 Chinese local >>>>>>>>> time, the patches got merged in 05:00 Chinese local time in the >>>>>>>>> next >>>>>>>>> day. There is no other developer gets CCed. There is no >>>>>>>>> reviewed-by. >>>>>>>> This is not to-be-abandoned solution. Adam, Aline, Shao He and I >>>>>>>> have >>>>>>>> discussed this in a team meeting. >>>>>>>> It is sent to mail list. all people subscribed to mail list should >>>>>>>> get it. >>>>>>>> It is already V5, it is reviewed enough. >>>>>>>>> After talked to Shao He this morning, he told me that we >>>>>>>>> determined to >>>>>>>>> defer this feature/task to seek a better solution. Shao He told me >>>>>>>>> that >>>>>>>>> they sent the patch as RFC, not aim to be a final solution. >>>>>>>>> However it >>>>>>>>> is a big misleading to other developers because there is no RFC in >>>>>>>>> the >>>>>>>>> patch title. There is even no reviewed-by. Is there any reason to >>>>>>>>> merge >>>>>>>>> it so hurry? >>>>>>>> This is already V5, how can it be an RFC? >>>>>>>>> If there was any time and task pressure, I think as an open source >>>>>>>>> project, the progress should have some flexibility. We should not >>>>>>>>> write >>>>>>>>> code for a known broken solution, while there is obvious >>>>>>>>> alternative >>>>>>>>> solutions. This is very different from incremental development. In >>>>>>>>> incremental development, the direction and the solution is >>>>>>>>> correct, we >>>>>>>>> just completes the missing pieces step by step. In this case, the >>>>>>>>> solution and the framework itself is not so effective. Once it's >>>>>>>>> merged, >>>>>>>>> we started to rely on this, and changing and improving it would be >>>>>>>>> much >>>>>>>>> harder. >>>>>>>> Speed will always be most key to succeed for any organization. >>>>>>>> There is nothing broken, it works well. >>>>>>>> Improvement will never stop. >>>>>>>> >>>>>>>> Again, the overall solution is discussed across whole team in one >>>>>>>> of the >>>>>>>> Wed's team meeting. >>>>>>>> Cookie is the best way to store previousPage to reserve user >>>>>>>> context. If >>>>>>>> anyone see a better way than cookie for this issue, welcome to >>>>>>>> discuss >>>>>>>> with me. >>>>>>>> >>>>>>>> As zhengsheng point out, we need to try to improve that small bit of >>>>>>>> code to store previousPage into cookie. but again, it works well >>>>>>>> currently. >>>>>>>> But obviously, that is far from a justification to stop this patch >>>>>>>> from >>>>>>>> being merged. >>>>>>>>> on 2014/06/13 05:50, Aline Manera wrote: >>>>>>>>>> Applied. Thanks. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Aline Manera >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Kimchi-devel mailing list >>>>>>>>>> Kimchi-devel(a)ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>>>>>> >>