When i login as admin, show me "Access restricted."

[caoli]

admin/index.php
If i use correct user and password, the page can't redirect to index2.php.
But if i use wrong user or password, show me:
Login failed. Sorry, the username caoli is incorrect. Remember that your username and password are case sensitive.

why?

[buridan]

the cookie does not seem to be setting at all using php 4.3.5

[kevin]

I cannot repeat this behaviour on a PHP 4.3.8 or PHP 4.3.2 system.

Make sure that the "base URL" setting (as configured when installing) correctly matches the URL of the site. The only other thing that comes to mind is that perhaps it is setting the incorrect path in the cookie. You could try editing admin/include/cookie.inc.php so that $path is always set to "/"

[Alistair]

Hi,

I can repeat the error very reliably on IIS and latest PHP and MySQL. chaning the $path, doesn't seem to make any difference.

Alistair

[Alistair]

Hi all,

I had a bit of a fiddle with the index2.php code, as it seemed to me there must be some logic breakdown for the login not to be working. The code from index.php and validate.inc.php wasn't obviously problematic.

In index2.php, lines 42-46, there is a routine that recalls the validate function

// validate the user's username and password, and formard to login page if invalid
if(!validate($username,$password)) {
Header("Location: ".$baseurl.print_url("admin/index.php"));
exit;
}

I was a bit puzzled why you would re-do this when index.php seems to be validating the username and password and then forwarding to index2.php.

Also, the statement

if(!validate($username,$password))

didn't seems right to me.

So, I commented out all the code and can logon with the correct username and password. Logon is also blocked if the wrong username/password combination is used. So, at the level of brief testing, this bit of code seems to be the problem and deleting it fixes the problem. I don't know if there is some permissions consequence yet, but I can't see why there should be from the code.

I also rewrote the code as follows:

if(validate($username,$password,false))

and this worked just as well as removing the code block entirely.

So, I hope that is helpful for people who might have this problem. I will run my system with the code commented out for now and see how it functions.

I would appreciate it if any code gurus could let me know if this will cause some fatal flow-on error in the OCS system, though I can't see it.

Cheers for now. And merry Xmas

Alistair Campbell
JCU
Townsville

[Alistair]

Hi,

It turns out that most of the php files in the /admin folder contain the code that seems to cause the problem.

I have gone through and replaced all of the

Code: Select all

 if(!validate($username,$password)

with

Code: Select all

 if(validate($username,$password,false)

and that seems to do the trick.

But as there may be other parts which use this validate code it is possible that the same error will recur.

I am not sure whether the keyword "false" is necessary as I found that

Code: Select all

if(validate($username,$password)

worked just as well. But, I will stick with the "false" option as it seems to make more sense... at this point.

Alistair

[kevin]

The changes you made remove authentication from the admin pages -- anyone can access your conference admin without logging in.

It appears on your system the validation cookie is not getting set correctly during login -- does a "confadmin" cookie show up in your browser's list of cookies?

[Alistair]

Hi Kevin,

no it doesn't look like any cookies are getting posted at all. Can you point me to the code that should be doing this?

Thanks for the "heads up" re those changes.

Alistair

[Alistair]

Hi Kevin,

I have text searched validate, commonn, functions, and cookie .inc.php and not been able to find the functions setadmincookie() or getadmincookie(). Is it possible that it could have been left out?

Alistair

[kevin]

Those functions are in admin/include/cookie.inc.php

[Alistair]

Hi,

I think I have found the problem... for my system anyway. Basically, the cookie doesn't get set until/unless the page where it is used is loaded/re-loaded. Therefore, in the logic of the code for OCS, the cookie is not set when it is called by index2.php.

If you refresh the page before calling index2.php the cookie is set and ready to be accessed.

I refreshed the page like this:

Code: Select all

$sUrl = $_SERVER['HTTP_REFERER'] ;

echo "\n<meta http-equiv=\"refresh\" content=\"0;URL=$sUrl\">\n";


after the setcookie() calls in the setadmincookie() and deleteadmincookie() functions.

This fixes the problem and the security of the system is maintained.

I don't know if this is a particular problem for IIS or the logic of the program flow. I hope this is helpful. I notice this thread is getting a lot of views so I wonder if this is in fact a common problem. It might be worth adding this to a code upgrade and flagging this post in the meantime.

Cheers

Alistair Campbell
James Cook University
Townsville

[kevin]

Comments at http://php.net/setcookie suggest this is a common IIS problem.

[Alistair]

Hi Kevin,

I thought that the issue was a PHP one but obviously not. If it doesn't break the Apache/MySQL/PHP setup, would it be worth including the additional code that I wrote in the standard configuration of OCS?

If not, I would be happy to send you the modified code that I have as an IIS distribution. Failing that, others who need an IIS fix can email me at Alistair.Campbell at(put in the symbol)jcu.edu.au.

Cheers

Alistair Campbell
JCU

[kevin]

It's unlikely that we will be releasing any updated versions of OCS (at least with the existing code base), but it would be great if you could post your code changes in the forum, for anyone with a similar configuration to use.

[rthomas]

I'm seeing this same behavior, but I'm not running IIS. I'm on OS X (10.3.9) w/ built-in apache and php 5.03.

So I tried the recommendations below. Cookie path is correct, "/". I tried Alistaire's code, but it had no effect.

Please help.

Thanks.