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

[Yu Xin Huo]

On 6/15/2014 12:38 AM, Aline Manera wrote:
>
> Sheldon, Yu Xin:
>
> I identified 2 issues in this new flow
>
> 1) The username is not being displayed
>
>
in login.html.tmpl, add one line code.
function updateBtnLabel() {
     document.getElementById("login").style.display = "none";
     document.getElementById("logging").style.display = "";
kimchi.user.setUserName(document.getElementById("username").value);
}

this line of code will store a 'username' attribute into cookie, for the 
left, original popup login window code will handle to add user name to UI.

>
> 2) When I access 
> "https://localhost:8001/vnc_auto.html?port=64667&path=?token=Fedora&encrypt=1" 
> without be
> logged in, I am redirected to the login page and after it I got the 
> Guests tabs instead of the VM console
After some investigation, backend has not handled the first time user 
paste a url(vnc_auto.html or /#tabs/templates),
For current design, the brower url will always taken as 'previousPage' 
and stored in cookie.
Shao he will add code to handle it.
>
> The logic to do the proper redirect to the VM console is in 
> kimchi.login_main() (ui/js/src/kimchi.login_window.js)
> I am wondering why we are not using it
> In the login.html.tmpl, we are using local functions to do the login, 
> I think we need to call kimhi.login_main()
> instead have JS into login.html.tpml
Some code there are bind to UI structure and can only apply to login 
popup, can not reused.
As there are too few css/js code in current login.html, so leave it 
there, but it is quite easy to separate those code to js, css files.
>
> Please, send a patch for those issues AS SOON AS POSSIBLE as kimchi 
> 1.2.1 will be released next Friday (June 20)
>
> Thanks,
> 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.
>>
>> 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.
>>
>> 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?
>>
>> 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.
>>
>> 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
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140616/e2133c4a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1924 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140616/e2133c4a/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbgjebah.png
Type: image/png
Size: 7870 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140616/e2133c4a/attachment.png>