[Tickets #8310] After a bad login a successful mobile login takes the user to DIMP as opposed to MIMP

bugs at horde.org bugs at horde.org
Wed May 27 13:29:48 UTC 2009


Ticket URL: http://bugs.horde.org/ticket/8310
  Ticket             | 8310
  Created By         | rorymckinley at gmail.com
  Summary            | After a bad login a successful mobile login takes the
                     | user to DIMP as opposed to MIMP
  Queue              | MIMP
  Version            | 1.1.1
  Type               | Bug
  State              | Unconfirmed
  Priority           | 3. High
  Milestone          |
  Patch              |
  Owners             |

rorymckinley at gmail.com (2009-05-27 09:29) wrote:

When connecting to a horde instance, I am routed to the mobile version  
of imp/login.php. If I incorrectly enter the wrong password, I am  
rerouted back to the mobile version of login.php. If I get my password  
correct this time, I get routed to the DIMP interface as opposed to  
the MIMP interface.

The cause for this behaviour lies in imp/redirect.php:

When I first hit the login page - my login url is  
blah.com/imp/login.php?url=%2Findex.php. When I submit my details,  
imp/redirect.php looks for a value of $GLOBALS['url_in'] (passed by  
the login page) in the _newSessionUrl function. If $GLOBALS['url_in']  
is set, then the url to which I am redirected is defined by $url =  
Horde::url(Util::removeParameter($GLOBALS['url_in'], session_name()),  
true). This works.

However, if I put in a bad password, I get redirected to a url that  
looks something like this...

If I log in now, redirect.php cannot find a value for  
GLOBALS['url_in'] - and _newSessionUrl calls this line of code:
  return Horde::url($GLOBALS['registry']->get('webroot', $view) . '/',  
true); (line 295)

As a result I am routed to DIMP. It currently looks as if the problem  
is caused by the fact that the GLOBALS['url_in'] variable is not set  
after a good login from the login page after a bad login. This is  
currently only a problem for mobile logins.

I do not know enough about the code base to determine if the problem  
lies with redirect.php or the way that the login page is populated  
after a bad login.

More information about the bugs mailing list