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

[Aline Manera]

On 06/13/2014 04:12 AM, 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.

I am not aware about ANY discuss you have just mentioned.
ALL discussion related to patches/features **MUST BE DONE IN THE MAILING 
LIST** to the
whole team be aware about it!

And in a V5 patch, you have more than enough time to do it.

> 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.
>
> 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.
>
> 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.
>
> 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.

If I applied the patches I reviewed it!

> 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?

An RFC named as V5?
A V5 patch set is to "be so hurry" for you??

>
> 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.

If you think you solution is better, send the patch!

> on 2014/06/13 05:50, Aline Manera wrote:
>> Applied. Thanks.
>>
>> Regards,
>>
>> Aline Manera
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>