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

[Aline Manera]

On 06/14/2014 01:18 PM, Aline Manera wrote:
> 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 OR DURING THE SCRUM MEETING** to the
> whole team be aware about it!

Sorry, I forgot to mention the scrum meeting

> 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
>>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140614/d6ca7663/attachment.html>