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

Are you responsible for making OCS work -- installing, upgrading, migrating or troubleshooting? Do you think you've found a bug? Post in this forum.

Moderators: jmacgreg, michael, John

Forum rules
The Public Knowledge Project Support Forum is moving to http://forum.pkp.sfu.ca

This forum will be maintained permanently as an archived historical resource, but all new questions should be added to the new forum. Questions will no longer be monitored on this old forum after March 30, 2015.
caoli

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

Postby caoli » Tue Aug 31, 2004 7:43 pm

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

same problem

Postby buridan » Fri Sep 24, 2004 10:12 am

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

kevin
Posts: 338
Joined: Tue Oct 14, 2003 8:23 pm
Contact:

Postby kevin » Fri Sep 24, 2004 12:15 pm

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

changing $path

Postby Alistair » Tue Dec 21, 2004 12:16 am

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

"Access restricted" issue

Postby Alistair » Tue Dec 21, 2004 4:53 pm

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

Update code changes

Postby Alistair » Tue Dec 21, 2004 5:59 pm

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
Posts: 338
Joined: Tue Oct 14, 2003 8:23 pm
Contact:

Postby kevin » Tue Dec 21, 2004 9:09 pm

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
Posts: 17
Joined: Tue Dec 21, 2004 6:02 pm
Location: Australia
Contact:

confadmin cookie

Postby Alistair » Tue Dec 21, 2004 9:52 pm

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
Posts: 17
Joined: Tue Dec 21, 2004 6:02 pm
Location: Australia
Contact:

setadmincookie

Postby Alistair » Tue Dec 21, 2004 10:07 pm

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
Posts: 338
Joined: Tue Oct 14, 2003 8:23 pm
Contact:

Postby kevin » Wed Dec 22, 2004 9:44 am

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

Alistair
Posts: 17
Joined: Tue Dec 21, 2004 6:02 pm
Location: Australia
Contact:

A work around but I need some help...

Postby Alistair » Wed Dec 22, 2004 10:26 pm

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
Posts: 338
Joined: Tue Oct 14, 2003 8:23 pm
Contact:

Postby kevin » Thu Dec 23, 2004 12:13 am

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

Alistair
Posts: 17
Joined: Tue Dec 21, 2004 6:02 pm
Location: Australia
Contact:

Does it just relate to IIS

Postby Alistair » Thu Dec 23, 2004 6:09 am

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
Posts: 338
Joined: Tue Oct 14, 2003 8:23 pm
Contact:

Postby kevin » Thu Dec 23, 2004 9:05 pm

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

Seeing this on OS X, apache, w/ php 5.03

Postby rthomas » Thu May 26, 2005 8:58 am

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.


Return to “OCS Technical Support”

Who is online

Users browsing this forum: Majestic-12 [Bot] and 1 guest