[Kimchi-devel] [PATCH V5 0/5] Switch to a traditional login flow
Aline Manera
alinefm at linux.vnet.ibm.com
Sat Jun 14 16:38:26 UTC 2014
Sheldon, Yu Xin:
I identified 2 issues in this new flow
1) The username is not being displayed
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
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
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/20140614/525a52d5/attachment.html>
-------------- next part --------------
ÿØÿà JFIF ÿÛ C
#
,(
"74'
)49. ',4=<3$.018242ÿÛ C 2222
!2222
22222!22222222222222222222222222222222222222ÿÀ , ç" ÿÄ
ÿÄ
ÿÄ µ } !1AQa"q2¡#B±ÁRÑð$3br
%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz
¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚáâãäåæçèéêñòóôõö÷øùúÿÄ µ w !1AQaq"2B¡±Á #3RðbrÑ
$4á%ñ&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz
¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚâãäåæçèéêòóôõö÷øùúÿÚ ? æµ]kPyVßS¾5w8ÒF!æL
ZN¬NYY$[þ-Oþúýýoñ¦kÍþ7ýtäSYÛ¨Sþ-Oþúýýoñ£þ-Oþúýýoñ¬½Ôn
OøHµ?úê÷õ¿ÆøHµ?úê÷õ¿Æ²÷Qº5?á"Ôÿ è/¨ßÖÿ ?á"Ôÿ è/¨ßÖÿ ËÝFê Ôÿ Sÿ ¾¡ÿ [ühÿ Sÿ ¾¡ÿ [ük/u¨Sþ-Oþúýýoñ£þ-Oþúýýoñ¬½Ôn
OøHµ?úê÷õ¿ÆøHµ?úê÷õ¿Æ²÷Qº5?á"Ôÿ è/¨ßÖÿ ?á"Ôÿ è/¨ßÖÿ ËÝFê Ôÿ Sÿ ¾¡ÿ [ühÿ Sÿ ¾¡ÿ [ük/u¨Sþ-Oþúýýoñ¨çñ.ª1³YÔ,1·Ì*=
IÔV~êfû¿ïÇÿ £6?á"Ôÿ è/¨ßÖÿ ?á"Ôÿ è/¨ßÖÿ ËÝRÛÁ$¬«m<DƽdÎ QþÑ ÿ ðjôÔ?ïëðjôÔ?ïëzþÏâ,¦µj×8Ýö=iAsOöytÑI<l XÛ¬nÃý@ðjôÔ?ïëðjôÔ?ïëeî£u jÂE©ÿ Ð_Pÿ ¿þ5
þ%ÕF6k:å&"VùåPA磩 úÏÝQÌßwýøÿ ôrÐÔð®ü/ßÁþ
ô¶ ÛKÿ
çÂÿ ô'øsÿ bÿ âktç±>ß_z0ßÞ4ò[ý&oúë ÿ ÈY»ª÷Ûý*úë ÿ ÈY¨]Ôn¨·Qº%ÝFêu¨]Ôn¨·Qº%ÝFêu¨]Ôn¨·Qº%ÝFêu¨]Ôn¨·Qº%ÝFêu¨]ÔÉîÿ ¿þZnêk7+þüú9h}Õ³á[
N{ÿ °lZêájÅÀ [°9Ø@
è9"°wWeà/Ø~oüJ~Ùælÿ |#û
Û½¨Úÿ áhiû¼¿±j_ÚYò?°ü³¿ÏÇü÷û»qÎíøÛót¯ ñU§ÌÛÖ-kpìu "à.ÂêH#$ ô<^ÿ
(?èTÿ ÉþÕ\g~%ÿ ny_ñ)û¿þZnó¼ýì.6í÷ bÒÙæ`°¼
Ç;ZYmüÓHTr=5ÖÂñwý ò4_ür¸ÕÚÚ|dס´0Å<`ámlïÔ ö6q¦6Å´H
÷<APgPÓî-dd½HÖU>Tè¬#v.¯CÏÍR¾ïûñÿ èå¦î¦³r¿ïÇÿ £>Æöï_Òzî?ýtyGÐPÉ^%oô¹ÿ 묣ÿ #5enô»úí/þjÊÍ IºÕ
hÍ IºÕ
hÍ IºÕ
hÍ IºÕ
hÍ IºÕ
hÍ IºÕ
hÍ IºÕ
hÍ IºÕ
hÍ IºÜ¯ûñÿ èå¨óJæO÷Óÿ F ?uª<Ñ uª<Ñ uª<Ñ u¹_÷ãÿ ÑËQæÌï§þZ û8?¥.ñýúiÆ:§¥7> ÿÙ
More information about the Kimchi-devel
mailing list