How 'Login' Should Work#

Wiki's are great conceptually because they follow the "REST" paradigm, and offer a set of pages just like the web which have addresses and can be easily linked to. Each page has an address. You can go to any page, and bookmark it in your browser, and get back to that same page later.

But logging in and out causes a problem. If you view "Login" as a "place", then you have to leave the page to go to that place. If you bookmark a particular page that you want to refer to often, but can see it only when logged in, the act of logging in takes you away from the page that you are interested in.

After noodling on this for a long time, I (and many others) have come to the conclusion that the Login should not be a "place" that you go to. Instead it should be more like a mode of the place that you want to see.

Here is how it should work: you navigate to a page by using one of your bookmarks. When you get to the page, you don't see the page, but instead see a message saying that you are not authorized to see the page. You also see a button to log in (or possibly to log out because you may be simply logged in as someone else who does not have access.) Pressing that button causes the login prompt to be displayed, but if you look at the address bar, it still shows the same address as before. You fill in the username and password, and click the "log in" button. Assuming you did this correctly, the next thing you see is the page you originally were looking for.

Example Scenarios#

Imagine someone using both Internet Explorer and Mozilla (because sometimes a site simply requires one or the other). In Mozilla you are logged into JSP Wiki and have been accessing pages there. But in IE you are browsing and click a link that takes you to a page on that Wiki. Because you IE is not logged in you get a page that displays a message. Because you have not been redirected to an error page, you are actually still on the page. It simply displays the message instead of the page. You select the address in the address bar, copy, and paste that address into Mozilla. The page appears in Mozilla because you still have a valid login session there.

It is very very convenient that the error message did not change the address in the address bar. After all, the resource you are looking for on the web is not the error message. Rather, you have reached the resource you intended, just that resource does not appear to you due to access restrictions.

Redirecting of the browser should be used when you use a address of a resource which is not the right address, and you should use a different address. So it forwards you there. After redirection, the address shows the new (correct) address for the resource. If you bookmark this new address, you will get back to this resource. This is how the web should work.

If a page requires you to be logged in in order to see the page, then access to that page without being logged in should simply show the login prompt. Your browser should not be redirected to a Login page. When you successfully complete login, you see the contents of the page.

The second scenario is when you are looking at a great wiki page, and you want to send a link to a friend. You go to the address bar, select, copy, and past that address into an email message. Your friend receives the email, they click on the link, what do they see? In the current implementation of JSP Wiki, their browser will be redirected to an error message or a login prompt. ASsuming that they log in successfully, then will then see the main page of the wiki, NOT the page that you sent them. The address of the page you sent them has been lost.

Third scenario: you follow a link to a page in teh wiki, and you are allowed to see the page without logging in, but you want to edit the page. To edit, you need to log in, so you click the login link. After logging in, you find that you are still on the same page that you were on before, only the edit button is enabled since you are now logged in as the right person to edit it. Currently JSP Wiki takes you to the Main page after logging in, and that is a little annoying.

Implementation Details#

This is not hard to implement. There is a quick and simple change that could fix most of this behavior. Currently the login link is to "Login.jsp" and does not have any parameters. This can be changed to have a parameter which is the name of the page that the Login link is appearing on. Clicking on the Login link would exactly what it does now, but when the login is successful, it would redirect the browser back to the page that you were looking at when you clicked the login link. This would be a huge benefit because when looking at a page, you can login and still be on the same page.

A better implementation is that if you are required to be logged in to see a page, the "Wiki.jsp" woudl simply <jsp:include> the login prompt directly into the page output, in place of where the page content would typically show. Once they log in, they get the actual page content instead of the login prompt. The result is that you actually have NO login page, no login address, but in fact every page becomes a login page if you are not logged in and you need to be.

-- Keith Swenson

This would be useful, agreed. If you have code to contribute, that would be great. Otherwise you're gonna have to wait until someone else gets around to doing it... ;-)

-- JanneJalkanen


Your main point appears to be this: "If a page requires you to be logged in in order to see the page, then access to that page without being logged in should simply show the login prompt. Your browser should not be redirected to a Login page. When you successfully complete login, you see the contents of the page."

That is exactly how standard J2EE container-managed security works, which is something JSPWiki supports -- all an admin needs to do is make a tiny configuration tweak to JSPWiki's web.xml file. It is also how JSPWiki's own custom authentication system is supposed to work, but in recent builds a bug was causing it to cycle back to the login page. The two systems (container and custom auth) function identically except for one minor detail: if you use container authentication, the user sees the original URL they intended. But with custom authentication, you see a Login.jsp URL. Regardless of what the user sees as the URL, though, the net effect is the same: if an anonymous user tries to access a page directly that they aren't supposed to see, they get a login prompt, after which they are directed to the page they wanted to see.

Am I missing something? It seems we've got your issue covered, especially when you use container managed authentication. As for the custom-authentication case, what you are asking is for us to re-write the page, in place, and replace the contents with a login prompt. I can see why you might want to see this, but it is not likely that we'd ever implement such a feature.

--Andrew Jaquith, 02-Jan-2007


The J2EE authentication is consistent with the way I suggest it should work, but it is a little too severe: you can not see anything unless logged in. This is also consistent with HTTP authentication, where the challenge and the subsequent login request stays on the same address -- there is no separate address.

The Wiki is a little more flexible than this, there are many modes of operation, but the one I need most commonly is: it allows viewing of pages when not logged in, but editing of the page allowed only when you are logged in. This is supported very well with the current implementation. The page has a particular address; the page at that addres either appears with or without edit button depending upon whether you are are logged in. The description at the top covers this case, as well as a number of other cases, in the desire to set forth a design principle

The main inconvenience I encounter in the current release: I browse around and find a page without being logged in. I want to edit that page so I click the login button and enter username/password. As a result of this, I find myself at the main wiki page and I have to browse, sometimes several clicks and scrolls, to get back to that page. Maybe if it is in the breadcrumbs it is only one click. But the point is that going back to the main page is NEVER what I want.

Janne challenged me to contribute something. I have been browsing around the code, which is a bit of a learning experience due to the amount of custom tags. I have discovered that the "Login.jsp" page is prepared to receive a "redirect" parameter, and if that is supplied, will go to that page after login. The only problem is that the "Login" link on all the pages does not include that redirect parameter. In my version here, I made a small change (two lines) to the "PageActions.jsp" to include the name of the current page in the Login link, and it works! When I am on a page, and click "login" I end up back on that same page after login. I added a few lines to "Logout.jsp" to accept a similar "redirect" parameter and Logout works the same way.

I believe this is the desired behavior: viewing a page, login and stay on that page, logout and stay on that page. It is not quite perfect from a purist point of view: the address of the page that displays the login prompt is different from the page. This is acceptable since requesting login is not a proper "state" of the session (but it could be....). However in cases where the page can ONLY be viewed when logged in it would be convenient to put the login prompt directly on the page.

Assuming there is agreement that this is an improvement (and there is evidence for this since it appears that it was already half implemented this way) I would like to check this change in, and I am trying to figure out how to do this.

-- Keith Swenson

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-7) was last changed on 14-Jan-2007 21:35 by KeithSwenson