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: