Implement "go back" functionality from login page

[Brian Koontz (brian@…]

This was a hack originally designed to facilitate entry into a Wikka installation from an external source and require a valid login for some particular action. Basic operation: Immediately prior to a Redirect to the UserPreferences page from another Wikka page, the page needs to set a session var called "go_back" with a valid link to the referring page. After a user is successful in logging in, they are redirected back to the calling page. This would be useful for actions or handlers that are linked to from the outside world, but that require a user to be logged in.

Here is a patch that implements this:

===================================================================
RCS file: RCS/usersettings.php,v
retrieving revision 1.1
diff -u -r1.1 usersettings.php
--- usersettings.php    2006/06/18 06:03:03     1.1
+++ usersettings.php    2006/06/24 06:40:13
@@ -1,5 +1,7 @@
 <?php
 /**
+ * $Id: usersettings.php,v 1.5 2006/06/24 06:40:07 brian Exp brian $
+ *
  * Display a form to register, login and change user settings.
  *
  * @package            Actions
@@ -334,6 +336,13 @@
                // is user trying to log in or register?
                if (isset($_POST['action']) && ($_POST['action'] == 'login'))
                {
+        // Login request was redirected from elsewhere...let's make
+        // sure to go back if requested by setting $referrer
+        $referrer = null;
+        if(isset($_SESSION['go_back'])) {
+            $referrer = $_SESSION['go_back'];
+        }
+
                                // if user name already exists, check password
                                if (isset($_POST['name']) && $existingUser = $this->LoadUser($_POST['name']))
                                {
@@ -349,7 +358,11 @@
                                                                                break;
                                                                default:
                                                                                $this->SetUser($existingUser);
-                                       $this->Redirect($this->href());
+                    if($referrer == null)
+                                       $this->Redirect($this->href());
+                    else {
+                        $this->Redirect($referrer);
+                    }
                                                }
                                }
                                else // otherwise, proceed to registration
@@ -417,7 +430,11 @@
 
                                                                                // log in
                                                                                $this->SetUser($this->LoadUser($name));
-                                       $this->Redirect($this->href('', '', 'registered=true'));
+                    if($referrer == null) 
+                                       $this->Redirect($this->href('', '', 'registered=true'));
+                    else {
+                        $this->Redirect($referrer);
+                    }
                                                }
                                }
                }
@@ -542,4 +559,4 @@
 <?php
                print($this->FormClose());
 }

---

Implement option 3 (see comments).

Related tickets #396

[DotMG]

Done [248].

[DarTar]

Excellent addition. Maybe we should consider making this configurable (some users may still want to be redirected to the user settings). Or—alternatively—use a delayed redirection, à la MediaWiki, allowing a user to click on other links before the redirection is triggered?

[DotMG]

I don't like the first option! Making things configurable is good, but a lightweight tool overconfigured would become too heavy to maintain. Look! We still don't have an admin panel!

I prefer the second option, but I have also a third proposition : Add a checkbox in usersettings.php to let user choose if he wants to be redirected to the referring page or to usersettings.

_ Check this to return to HomePage.

The advantage is that it is easiest to implement than the 2nd choice, the user has the final choice, and there is one less request to server.

[DarTar]

I definitely like your option 3 and agree we shouldn't clutter up the config file with silly thingies. But at the same time a serious approach to user preferences would be to store them in the user table (we should not use sessions for relatively stable preferences). So, unless others have something to say on this point, I suggest to go for option 3 and keep in mind that later we'll have to move this to a real user preferences panel.

[MasinAlDujaili]

I might be a little bit too enthusiastic about my own idea, but what about metapage like UserName/config -- might also be implemented as a handler. But I like the idea of a personal user config page more.

Using Wiki pages for config might even have some more benefits, e.g. ease of adding more options when necessary. It doesn't require to edit the database tables. Also, any user is thus able to simply export her own configurations for use with another Wikka.

In the wikka.config.php we'd put only those configurations absolutely needed for database access and global configurations (pathes and similar). Default config values might be put to HomePage/config as this page should always be existant.

[DotMG]

Letting user choose where to be redirected to, see description!

[DotMG]

Done ([253]). Discussion related to configuration should go to #396.

The checkbox label became "Don't go back to %s". I will explain why: If user is logging in, he checks or unchecks a checkbox and fill other field of the form. If he made a mistake (e.g. wrong password), he should not re-check or uncheck the checkbox: it should have its previous state. So, just look if $_POSTno_go_back? is set, and if it is, add checked="checked". On the other hand, the default behaviour should be to redirect to referring page. So, by default, the checkbox is unchecked.

If the approach seems unaccomodating, I can still change the checkbox with a radio button ... Feel free to reopen the discussion.

[DarTar]

Mahefa, I'll take a look at your implementation, thanks for the commit.

Masin, my answer is: why not. What you're suggesting is a high-level consideration on how to call specific administration modules (using the handler syntax makes sense, but we could also use the : operator). But this leaves open the question of how to implement these admin modules.

[DarTar]

(In [553]) Changing ERROR_NO_WRITE_ACCESS to make the most of the new "go back" functionality, refs #245

[DarTar]

(In [554]) Fixing code soup created by previous commit [553] because of wrong encoding (apologies) refs #245

[DotMG]

(In [1200]) refs #245

backporting [248] and [253] to milestone:1.1.6.6