Hello P,
On Friday, December 13, 2002, p dont think wrote...
>> > After I entered my username and password I get to the page
>> > /src/webmail.php and I see the following. Isn't it interseting that
>> > we _see_ my username+domain after 11, 12 and 13 below?
>>
>> Not really. You'd expect that output. You cannot get a value from a
>> session you haven't started up. It's like doing this:
>>
>> echo $a;
>> $a = 15;
> However, the session should have already been started in redirect.php,
> so in fact, that shouldn't be an issue (although it clearly seems that
> that *is* the issue - Jonathan, do you know of any reason why the
> session would not start in redirect or somehow get terminated between
> there and webmail?).
From what I have been learning about sessions, they must be started
on each page to access session variables, not just on one page
(trust me, I'd love it if it was that simple).
> I am using session.auto_start = 1 in my php.ini settings, perhaps
> yours is = 0? This could be an issue, although again, it *shouldn't*
> be an issue, since the session is explicitly started in
> redirect.php.
The reason this is working for you is that every PHP page that is
being served is kick starting a session (even those without session
stuff), then PHP grabs the vars from the session settings in the
browser. The reason it isn't working in Lilla's case is the session
has to be started with code, which isn't done until further down on
the page.
> I've attached a debug version of redirect.php that should
> temporarily replace the one in the /src directory. Log in using that
> file and let me know what you see.
Looking at the code, the expected results would be:
username =
username = "their login"
[ then a load of errors about not being able to pass headers ]
> The next thing I can do is start the session in the vlogin plugin by
> testing if the current requested URI is "webmail.php"... that would
> be something of a hack, but not terrible. I'd rather understand why
> your session isn't starting where it should be before I do that,
> though.
To be honest, we've been having a lot of session issues recently,
which is why I am going to be sitting down over the weekend, and
having a long look at how we deal with them, and considering writing
a custom session handler. Unfortunately this probably wouldn't kick
in fully until 1.4/1.5. I guess a cheating way to get it to work
properly would be to change the order of some includes. If you open
src/webmail.php and at the top you have all the requires, change it
so it looks like this:
require_once('../functions/strings.php');
require_once('../src/global.php');
require_once('../config/config.php');
require_once('../functions/prefs.php');
session_start();
require_once('../functions/imap.php');
require_once('../functions/plugin.php');
require_once('../functions/i18n.php');
require_once('../functions/auth.php');
It'd have to be done in that order because their is some code in
src/global.php which forces a rename of session in 1.2.10. This is
to stop SquirrelMail breaking when other PHP applications use
sessions too, such as Gallery, or geeklog. I'm not 100% sure how the
above mentioned code would affect the SM interface on a whole
though. I did introduce a new function in 1.2.11[cvs] (bit late I
know) that checks for an active session (maybe devel wants to bring
it into play too). It's called sqsession_is_active. Basically it
checks to make sure you have a session id available (no session id
normally means no session), and it then starts one up.
--
Jonathan Angliss
([EMAIL PROTECTED])
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
--
squirrelmail-users mailing list
List Address: [EMAIL PROTECTED]
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
