6:42 a.m.
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
