[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"2B‘¡±Á	#3RðbrÑ
$4á%ñ&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz‚ƒ„
†‡ˆ‰Š’“”•–—˜™š¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚâãäåæçèéêòóôõö÷øùúÿÚ   ? æµ]kPŠyVßS¾Ž5wŠ8ÒF!æL
ZN¬NYŽY‰$“[þ-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Ýö=‡iAsŸOö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