+- UserSpice (https://userspice.com/forums)
+-- Forum: Support Center (https://userspice.com/forums/forumdisplay.php?fid=23)
+--- Forum: UserSpice 4.3 and Below (https://userspice.com/forums/forumdisplay.php?fid=26)
+--- Thread: mhhk im being dumb (/showthread.php?tid=359)
Pages:
1
2
mhhk im being dumb - raven - 11-22-2016
i just created a page off the blank droped it in usersc and set it to private how ever even not logged in i can view it oops i screwed bup somewhere but cant seem to find it
just an fyi i used the headcode from the blank php page but the body code from the index.php page because it suited what i needed for a lay out for that page
columns are nice ps word press needs spoilers
http://pastebin.com/2S8DBjJ6
it has a week to expire 11/22/16 pasted
mhhk im being dumb - mudmin - 11-22-2016
Hmm. Nothing jumps out at me. What did you call the page? In general, I don't build pages for the project in the usersc folder. You can just stick them in the root folder. usersc is primarily for overrriding existing userspice stuff. Try that before we dig too far.
mhhk im being dumb - raven - 11-22-2016
i can try that and the page is called sysmang.php
mhhk im being dumb - raven - 11-22-2016
nope in the site root and it says internal 500 error weird
mhhk im being dumb - mudmin - 11-23-2016
Ok. The only thing I did was changed the link to the init in this page...
http://pastebin.com/9Q2GxgJX
Put it in the root folder. Made it private and added Admin and Users to it and it worked fine for me.
mhhk im being dumb - raven - 11-23-2016
brillant now ill just clone that head code for other pages
also what would i use to code wise to add in say os tickets besides sharing the user database or creating some strange updating clone with cron :p should i just add the head code to all the other pages ? after its installed in the site root? i mean i dont see why that wouldnt work. i mean i dont have to it can stay as a stand alone system that would help prevent unforseen vulnerability i beleive. but then opens up the issues of them having to login to multiple sites to work eh choices lol simple or a lot of work hmm
advice?
mhhk im being dumb - mudmin - 11-24-2016
I might be missing something.
Let me see if I understand...
You are creating a support ticket program?
It sounds like you're creating something that would be on your own web host and people would come to you as opposed to being some sort of intranet type thing where people would logon from their work computers, right?
mhhk im being dumb - sabr - 01-15-2017
Hello,
I am relatively new to php development and I am looking into using UserSpice as a foundation for a new project.
One of the things i noticed was this issue mentioned here of pages being set to private in the control panel yet whilst not logged in I can still get to the page. Tested with /index.php. US_ver= 4.1.8c
Upon looking through the code I noticed there was no check being run on some of the pages, including /index.php, to see if the page is public or private and if the later which groups can see the page.
I then created /test.php which contains the following:
<pre>
Code:
<?php
require_once 'users/init.php';
require_once $abs_us_root.$us_url_root.'users/includes/header.php';
require_once $abs_us_root.$us_url_root.'users/includes/navigation.php';
?>
<br><br><br>
<p>this is a test page</p>I set the page to private with user group access. I could still view whilst not logged in.
Adding
Code:
if (!securePage($_SERVER['PHP_SELF'])){die();};As the system is designed to use page permissions this should probably be included in /users/init.php but as you pointed out in your troubleshooting video you cannot patch this file. Therefore I think it might be worthwhile being included in /users/includes/header.php.
Another thought on patching the init.php file is to make a init_fixes.php file which could search the init.php file for any necessary fixes and then output messages into a panel in admin.php with patch information.
As for Raven's system, I believe depending on the need for a support/ticket system then in some cases you don't want the general public being able to access and would require users to be logged in prior to being able to view/create tickets.
If I have missed something regarding the design or functionality then please enlighten me for future reference.
Hope this has been helpful (if not already fixed) and not rude newbie comments.
mhhk im being dumb - mudmin - 01-15-2017
Index.php does not have the check in it by default because if you locked people out of the homepage, then they wouldn't be able to login. You could always do
Code:
if(!$user->isLoggedIn){Code:
Redirect::to('users/login.php);Code:
}somewhere near the top of the index to force them to login without using the heavy handed security feature. I'm going to be cleaning up what happens when someone doesn't have access in 4.2. I've been testing it in some of my other projects.
One of the tough things is that we work under the assumption that there should be "public" parts of most projects where people can at least read a little information before deciding if they want to join or login. The above redirect would cause issues with that.
Is there another page that should be secured, that is not secured by default?
And yes...every UserSpice page that you want to be able to log people out of needs the
if(!securePage($_SERVER['PHP_SELF'])){die();};
line or UserSpice will know that you're not supposed to be there, but it won't be able to kick you out.
I don't think this can be in the init. I can double check that though.
I definitely appreciate your feedback and I'll look into the init fixes thing too. The main problem with editing the init is that it is created on the fly at install, so we don't know what's in there to find and replace things. We're moving more things out of it, to pretty much leave just the db credentials over time. It's tough when you're trying to maintain compatibility.
mhhk im being dumb - sabr - 01-15-2017
Is that not why the following is included in securePage():
Code:
}elseif ($pageDetails['private'] == 0){//If page is public, allow accessCode:
return true;so it allows access for public but then if it the page is set to private then it runs the rest of the checks for permissions.
In that case it is probably best for the snippet to sit in header.php, at least for myself anyway.
I suppose if people have implemented their own fixes in the init file as well then it would be telling them to fix something that has already been fixed. I can understand how difficult it can be to maintain compatibility, I think a lot of people appreciate your hard efforts.