Does the getParams() function include an action for ‘register’? I tried that at one point but didn’t seem to have any luck (before I tried the above idea).
getParams() gives info that Zend uses in its routing system, which is often confusing. It basically shows how Zend parses a URL to figure out which page to produce.
A URL like /guest-user/user/register will result in this from getParams():
[module] => guest-user
[controller] => user
[action] => register
So, in your checks for allowing access, you’d want to make sure that that combination is satisfied.
It might be more straightforward to just make your stuff in login.php link directly to the guest-user/user/register page. You’d end up redirecting there anyway, so it should be simpler to just us it directly
1 Like
So I’ve been trying to do just that today because I think you’re right, but no matter where I put this line, I end up with the redirect loop problem:
$this->_getRedirect()->gotoUrl(WEB_ROOT .'/guest-user/user/register');
I’m not quite sure if there’s something with the original registration file that is creating the issue or what. I tried creating a variable and line like the previous example you have above:
$registerAccess = false;
if ($requestParams['module'] == 'guest-user' && $requestParams['controller'] == 'user' && $requestParams['action'] == 'register'){
$registerAccess = true;
}
Then also doing:
if ($registerAccess) {
$this->_getRedirect()->gotoUrl(WEB_ROOT .'/guest-user/user/register');
}
But even if I leave all that out and just switch the redirect to:
if (!$user && !$allowAccess){
// check and redirect to registration page
$this->_getRedirect()->gotoUrl(WEB_ROOT .'/guest-user/user/register');
}
I still get the redirect problem. Does my logic make sense though?
Also, can you explain what you mean by this:
It might be more straightforward to just make your stuff in login.php link directly to the guest-user/user/register page
Do you mean the Omeka login.php page under /applications/views/scripts/users/login.php? Because I was changing the link in there yesterday to directly link (e.g.,<a href="../guest-user/user/register">Register</a> ), but I couldn’t get it to work.
So, at least as far as I understand the mission, there should be a default restriction on site access, which pushes everyone to the login page. Then, there are certain conditions which will not redirect everything to that page: 1) a user is logged in, so they get to look at everything, 2) they need access to the login page, 3) they need to get to the register page, 4) [I’ll get to 4 below]
So, the $allowAccess check is really just whether the redirect to login should happen. If any of the conditions for normal access are there, skip the redirecting. So, you could pile everything onto that one variable, $allowAccess:
protected function _preventSiteAccess($request)
{
$user = current_user();
$allowAccess = false;
$requestParams = $request->getParams();
if ($requestParams['controller'] == 'users' && $requestParams['action'] == 'login') {
$allowAccess = true;
}
if ($requestParams['module'] == 'guest-user' && $requestParams['action'] == 'register') {
$allowAccess = true;
}
// prevent access to site for anyone not logged in, including guests.
if (!$user && !$allowAccess){
$this->_getRedirect()->gotoUrl(WEB_ROOT .'/users/login');
}
}
This just piles up checks for whether to do the redirect with a sequence of ifs. If the pile of conditions are met, the redirect to login won’t happen, and users can happily go to their destination.
The links that you put on the login page to guide users where to go just have to have a corresponding check to allow access – I think that’s the base of the your second question about what goes into login.php?
And now for 4) from above. The login page, at least by default, includes a link if you have forgotten your password. That link should also get an if statement similar to the ones in the code above to allow access.
Whew! There’s a lot here, I know. But I hope this gets us on the right track.
1 Like
Thanks Patrick! So I guess the solution was (as usual) staring me in the face. And I was trying to make things more complicated than they actually are (also typical for me). I guess it was confusion over what the access variable was doing.
Anyways, I (you) got it to work. Hooray! Here’s the final code for anyone else looking to do something similar, with the extra check for the “forgot password” link added:
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$this->_preventSiteAccess($request);
$this->_preventAdminAccess($request);
$this->_warnUnconfirmedUsers($request);
}
protected function _preventSiteAccess($request)
{
$user = current_user();
$allowAccess = false;
$requestParams = $request->getParams();
if ($requestParams['controller'] == 'users' && $requestParams['action'] == 'login') {
$allowAccess = true;
}
if ($requestParams['module'] == 'guest-user' && $requestParams['action'] == 'register') {
$allowAccess = true;
}
if ($requestParams['controller'] == 'users' && $requestParams['action'] == 'forgot-password') {
$allowAccess = true;
}
// prevent access to site for anyone not logged in, including guests.
if (!$user && !$allowAccess){
$this->_getRedirect()->gotoUrl(WEB_ROOT .'/users/login');
}
}
OK - so I discovered a conflicting issue (or two) with this. Perhaps you can advise me on what else I need to change.
When I’ve modified the plug-in as we discussed, I get an error on the show.php page, that says:
Notice: Undefined index: module in [hostname]/omeka/plugins/GuestUser/libraries/GuestUser_ControllerPlugin.php on line 23
line 23 in that file is:
if ($requestParams['module'] == 'guest-user' && $requestParams['action'] == 'register') {
More troubling is a seemingly unrelated error: I can no longer delete items in the admin panel. In fact, I don’t even get an error, just a blank popup text box without the standard delete question. If you want to see the image (which I personally think is unhelpful) I can send it. This happens no matter where I trigger the delete — from the items list, within an item, after choosing first to “edit” etc. Why would this be happening?
I’m actually hoping that the two are related. Unfortunately, it’s due to me missing a detail.
In the second if statement…looks like line 23, change it to
if (isset($requestParams['module']) && $requestParams['module'] == 'guest-user' && $requestParams['action'] == 'register') {
$allowAccess = true;
}
Basically, ‘module’ is not set when it’s a page governed by a plugin, so it won’t always be there. This change just checks that it actually exists before trying to use it. My bad, sorry!
With this change, deleting items seemed to work again for me. I haven’t checked all the other pages, but I’m pretty confident that this’ll make things happier.
1 Like
You’re right - that worked! Thanks again. The explanation makes sense too.
Hello
I’m confronted with the same question of how to regulate access to the “public” items. I would like to use the existing clients and passwords, but have no idea of how to do so.
Is there someone who is experienced and could do it for us? If so, how much would that be?
Thanks for recommendations and ideas.
Best
Severin