verify.php bug and possible solution.

[anphung]

Hi, I would like to say a big thank you for such a wonderful project! Very nicely thought out and saves me months if not weeks of work.
I've installed the latest version 4.1.4b and initial testing worked extremely well.
However when I changed the admin email address, the system breaks down and sends me to a not found page with the
message:
The requested URL /userManagement/users/users/verify.php was not found on this server.
(where userManagement is the userSpice installation.)

I can't even log in!

I searched the forum and notice others are having similar (if not the same) problem.

Anyway, after much digging around, I found the bug in the verify.php:

verify.php
if($user->isLoggedIn()){
$user->logout();
Redirect::to('users/verify.php');
}

Simply change it to:

if($user->isLoggedIn()){
$user->logout();
Redirect::to('verify.php');
}

and you should be good to go. Note that if error still exist, close browser and log in again.
Not sure if this is the proper fix, please advice.

[mudmin]

Fantastic! Thanks for the compliments and thanks for offering a fix. That makes perfect sense. I obviously never would have come across that situation in my testing... but it makes perfect sense! Thanks again!

Sorry for the slow reply. I went to the Arctic Ocean and got stuck there longer than expected. I'm playing catch up.

[anphung]

hey mudmin, great having you back. Hope you had a good time in the Arctic, the word itself sounds extremely cold!
I will try debugging the code if I find any bugs and obviously the userspice community cannot just expects you to do all the hard work!

Keep up the good work!

[mudmin]

Thanks for all your help. I know that GlacierView Alaska is not exactly considered "modern" civilization, but it feels great to be back to where I have internet and heat. haha.

[plb]

This change to Redirect.php will solve this problem:

http://userspice.org/forums/topic/banned...t-log-out/

(you have to look several replies down)

Ultimately it would be better (as mentioned there) if each call to Redirect::to() used the $us_url_root.'full/path/to/script.php' - that definitely needs to be gradually implemented for the long-term as this (what I did in redirect.php) is just a hack-job to make it work.

[plb]

Basically the problem is that when you have a relative path (users/verify.php or just verify.php) then it is relative to your current directory. If you are on a page in the users/ directory then you need to redirect to verify.php but if you are on a page in the root directory (or some other application directory that your developer-who-is-using-US has created for their app) then you need to redirect to users/verify.php (or ../users/verify.php or ../../users/verify.php or etc.).

The right solution is to change the relative redirect into an absolute redirect:

Code:

Redirect::to($us_url_root.'users/verify.php');

but until that can be done across the board in all US scripts (and probably in applications that other people have developed and have used the Redirect::to() call and used relative paths as an argument) then a change/hack such as I have suggested in the link above will get past most of the pain.

[anphung]

yeah, absolute path would definitely work lol. However, what if I have a customized verify.php in the usersc/ directory? It wont get accessed! Correct me if I am wrong, my understanding of the design of the system is to allow all files under users/ to be customizable. I am sure the author used relative path for a good reason hence I stuck with the original design.
I wouldn't call the above a hack either but a minor fix for the system, i.e. a fix for version 4.1.5 perhaps?

[plb]

Looking at the code starting at line 25 on

Code:

header.php

(included in every US page) we have this:

Code:

//check for a custom page

Code:

$currentPage = currentPage();

Code:

if(file_exists($abs_us_root.$us_url_root.'usersc/'.$currentPage)){

Code:

if(currentFolder()!= 'usersc'){

Code:

Redirect::to($us_url_root.'usersc/'.$currentPage);

Code:

}

Code:

}

Here is the definition, roughly, of

Code:

currentPage()

(I've simplified it for brevity):

Code:

return(basename($_SERVER['PHP_SELF']));

So if there is a page existing in

Code:

usersc/

then this redirection will happen automatically and it will happen to an absolute path so that there is no ambiguity about that. Choosing a consistent way to specify Redirect:too() arguments will not harm the ability to override pages with

Code:

usersc/

.

Where I sometimes have questions is with the scripts that are require_once'd (i.e., not a "page" per-se). It appears that these are require_once'd from init.php with an absolute path and no use of include_path or anything. I *think* this means that

Code:

usersc/

cannot be used to "override" scripts which are include'd or require'd. But that's a totally different question, unrelated to the Redirect.php class.

[brian]

I'm surprised the absolute and relative variables are working as well as they are. That was an afternoon well spent I guess!

We are in the process of going through all the code for a far in the future release, and you have reminded us that we need to think about a few more scenarios. In my case, I've used UserSpice for one or two things, and that definitely helped flush out some bugs, but the more people use it and report back, the more we can fix.

You are absolutely right about the "currentPage()" functions and the other files that are require'd or require_once'd into the scripts. I think the idea there (and how we are trying to handle the next Major release) is that there would be one, or maybe two lines required to "secure" the page, while another 3-4 lines would be required to make use of the rest of the navigation, admin pages, footers, etc. In this respect, we are trying to "bundle" things together to minimize the number of lines required to get the full UserSpice environment versus just the page securing functionality.

@mudmin is working hard to keep up the patches on the 4.1.x release, while I'm working to try to make the next major release be something even more flexible.

[brian]

One of our ultimate goals is to have a "UserSpice Core" set of files that users don't need to, and shouldn't ever need to touch, with all customization being done to files either in the root or in usersc/ or some other custom folder. This involves moving some things to the database so that updates and upgrades will be as easy as extracting and overwriting any files in the update/upgrade package.

in a way, the usersc/ customization was our first crack at this approach, but we realize there are a lot of shortcomings of this approach.