View Issue Detail

ID	Project	Category	Submitted / Last Updated
00779	UserSpice	Misc Code	2020-01-10 13:55:09 / 2020-10-08 04:14:56
Reported	Dan Hoover	Assigned To	Unassigned
Priority	normal	Reported	5.0.08
Status	closed fixed	Resolution Version and Commit	5.1.5 ccf557
Summary	master urls are being regenerated in functions
Description	<p><span style="color: #dcddde; font-family: Whitney, 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 16px; white-space: pre-wrap; background-color: #36393f;"> $self_path=explode("/", $_SERVER['PHP_SELF']);</span></p>

November 2021

There were instances where users overrode abs_us_root and $us_url_root variables in the init.php file but functions were duplicating the original logic which caused some weird issues in very rare circumstances. This new logic ALWAYS uses those variables as declared in init.php.  Need to check for stability but all looks good.
November 2021

As far as I can tell, it's always OK (and desirable) to use "global $abs_us_root,$us_url_root" everywhere except init.php. The changes in 5.0.9 work but aren't complete. Here's the list of places I know about where these two variables are reconstructed locally in a function, but the function ought to use the globals that were set up by init.php: users/helpers/helpers.php, function email_body users/helpers/permissions.php, function securePage users/helpers/deprecated.php, function currentPageId With these areas patched to use the global variables, everything seems to work well even when UserSpice is installed in a subdirectory of the project DOCUMENT_ROOT. Also, in some places where the code is functionally correct and presumably has been edited, there is leftover redundant looping code that probably ought to be deleted: users/helpers/us_helpers.php, functions reAuth, isLocalhost, currentFile
November 2021

Steps to reproduce the problem: - install US in a subdirectory of DOCUMENT_ROOT - say, /us - patch init.php to set up $us_url_root = "/us/" - ask US to monitor directory .. (i.e. DOCUMENT_ROOT) and set some pages in that directory to be private - in one of those private pages, do the usual "if (!secure_page...) die;" - now access that page when not logged in - and you get taken to the wrong URL to login; the subdirectory /us component of the URL is missing because $us_url_root is wrongly calculated in users/helpers/permissions.php, and the user gets a 404. I have not yet tested any of the other functions that I identified in the previous note, but it seems likely that something similar will happen.
November 2021

Review issue #800 as well