<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/14/2014 01:18 PM, Aline Manera
wrote:<br>
</div>
<blockquote cite="mid:539C75D6.7000601@linux.vnet.ibm.com"
type="cite">On 06/13/2014 04:12 AM, Zhou Zheng Sheng wrote:
<br>
<blockquote type="cite">If I remembered correctly, Shao He, Yu Xin
and me had several long talks
<br>
on the login design. This solution is not the solution we
agreed, and
<br>
all of us thought that this solution is ugly and obviously
should be
<br>
improved.
<br>
</blockquote>
<br>
I am not aware about ANY discuss you have just mentioned.
<br>
ALL discussion related to patches/features **MUST BE DONE IN THE
MAILING LIST <font color="#ff0000">OR DURING THE SCRUM MEETING</font>**
to the
<br>
whole team be aware about it!
<br>
</blockquote>
<br>
Sorry, I forgot to mention the scrum meeting <br>
<br>
<blockquote cite="mid:539C75D6.7000601@linux.vnet.ibm.com"
type="cite">And in a V5 patch, you have more than enough time to
do it.
<br>
<br>
<blockquote type="cite">The problem is on how it redirects the
user back to the previous page
<br>
after login. In this patch, the back-end has to intercepts each
access
<br>
to any of the ".html" page, and sets
<br>
cookie['lastPage'] = current page URI,
<br>
and return it to front-end, then the front-end sends this cookie
to
<br>
back-end in every query, including AJAX query. When the session
expires,
<br>
the back-end redirects the front-end to a login page, after
login
<br>
successfully, the back-end gets cookie['lastPage'], at last,
redirect
<br>
the user to the last page.
<br>
<br>
Just to implement returning to the previous page afte login, the
<br>
back-end has to intercept each '.html' access and sets cookie,
and the
<br>
front-end has to send the cookie in each request including AJAX
ones.
<br>
<br>
So in the last talk we agreed that a simpler and more effective
solution
<br>
should be used. We at least have two alternative solutions.
<br>
<br>
1. When session is expired, we redirect the user to login.html.
After
<br>
login successfully, the JS script in the front-end asks the
browser to
<br>
go back to the previous page. Since the browser keeps a stack of
page
<br>
histories, it should be easy to do this.
<br>
<br>
2. When the back-end detects the session is expired or the user
hasn't
<br>
login yet, it uses internal redirect to present the
"login.html". From
<br>
the front-end point of view, an unauthenticated access to "GET
<br>
#tabs/vms.html" returns "login.html". After the user input
his/her
<br>
password in the "login.html" and click "login", the back-end
receives
<br>
the request, if the password is correct, it returns a
"refresh.html". In
<br>
"refresh.html" there is actually a small JS code to ask the
browser to
<br>
refresh the page. Since we are using internal redirect all the
time, the
<br>
page URI in the browser remains "#tabs/vms.html", so after the
login,
<br>
just refreshing the page would lead user to the real
"vms.html.tmpl".
<br>
<br>
In the above two solutions, no ugly cookie is needed for each
request
<br>
and response, and the back-end doesn't have to intercept each
".html"
<br>
access, but just has to intercept each unauthenticated access.
<br>
<br>
I don't know why Yu Xin and Shao He sent the to-be-abandoned
solution
<br>
again to the mailing list. Patches were sent on 20:00 Chinese
local
<br>
time, the patches got merged in 05:00 Chinese local time in the
next
<br>
day. There is no other developer gets CCed. There is no
reviewed-by.
<br>
</blockquote>
<br>
If I applied the patches I reviewed it!
<br>
<br>
<blockquote type="cite">After talked to Shao He this morning, he
told me that we determined to
<br>
defer this feature/task to seek a better solution. Shao He told
me that
<br>
they sent the patch as RFC, not aim to be a final solution.
However it
<br>
is a big misleading to other developers because there is no RFC
in the
<br>
patch title. There is even no reviewed-by. Is there any reason
to merge
<br>
it so hurry?
<br>
</blockquote>
<br>
An RFC named as V5?
<br>
A V5 patch set is to "be so hurry" for you??
<br>
<br>
<blockquote type="cite">
<br>
If there was any time and task pressure, I think as an open
source
<br>
project, the progress should have some flexibility. We should
not write
<br>
code for a known broken solution, while there is obvious
alternative
<br>
solutions. This is very different from incremental development.
In
<br>
incremental development, the direction and the solution is
correct, we
<br>
just completes the missing pieces step by step. In this case,
the
<br>
solution and the framework itself is not so effective. Once it's
merged,
<br>
we started to rely on this, and changing and improving it would
be much
<br>
harder.
<br>
</blockquote>
<br>
If you think you solution is better, send the patch!
<br>
<br>
<blockquote type="cite">on 2014/06/13 05:50, Aline Manera wrote:
<br>
<blockquote type="cite">Applied. Thanks.
<br>
<br>
Regards,
<br>
<br>
Aline Manera
<br>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
</blockquote>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>