User registration / login redirect page

Perhaps someone can advise me on the best method for what I want to do.

We have an Omeka Classic set up for our database, which for the moment I have hidden via an .htaccess file (username and password). This is because we are not yet ready to release it publicly.

We are currently discussing future access options for the public and would like to require a separate login. To be clear, this is a non-commercial endeavor, but for various reasons concerning the content of the site, we would like to create some kind of user registration or login to access even the content marked as “public.” In other words, we want to make the content free but require a user to login (in much the same way as you might have on, say, a library website or an open access journal site). At the moment we believe users will visit the site primarily one of two ways: individually (such as through a direct link we publicize, or following a Google search) or via a library website (grouped together with other databases, i.e. through a library portal that requires a login).

My question is: what’s the best way to do this? To create a separate registration/login process that then redirects to the Omeka database index page following a successful login? If so, can you recommend a place to get coding models that would work well? I found a few examples by Googling (e.g., http://www.wikihow.com/Create-a-Secure-Login-Script-in-PHP-and-MySQL), but I’m unsure which follow good coding practices and which are outdated.

Thanks!

If you have some developer time, a modification of the Guest User plugin might do the trick. At the most simple level, it creates a user login that has no access to the admin side, but allows access to whatever else is public. Changing the Access Control List there might do the trick, though the ACL system is sometimes mystifying to me. Seems like something similar should do the job one way or another.

1 Like

Thanks Patrick, I’ll try that out.

Hi there, i’ve got the same problem here - I want to give registered guest users access to unpublished items but not to the admin backend. It would be great to know where I can find the Access Control List you mentioned Patrick. Thanks Jan

Just an update. So, I started looking into the modification mentioned above, but we had several more meetings and we decided we might go a slightly different route: institutional access only, i.e. through likely IP restrictions (so that people would have to proxy in through, say, their local library to use it). Although this isn’t my favorite method, it’s probably the most secure way for the long-term - and I won’t have to worry so much about controlling registration and login.

With that said, we want to set it up so that the first time someone comes to our page, they must agree to Terms & Conditions before viewing any content - this notice would essentially be a pop-up where they check off “I agree.” Afterwards, when they return again, they would ideally not have to do this again. I was thinking I’d just set up a persistent cookie. My question is: what’s the best method of handling this in Omeka?

Well, we’re back again to wanting the user registration page. Only this time, I’m told that all we want is automatic user registration for legal purposes. More to the point, we aren’t going to have money in the long run to actually maintain users. But the PI has said all he cares about is legal issues and thus he just wants to have proof we have registered people in the system (fake names don’t even matter, this is all legal mumbo jumbo).

So what I need to do is: 1) figure out some way to deal with user registration that doesn’t involve us having to approve anyone on the back end, they do a confirmation through email and 2) in that initial registration they get the terms and conditions.

One will not able to access the contents of the Omeka site, i.e. see any of it, without first going through this registration which, as I said, only matters for legal reasons.

If it were you - what would you do? @patrickmj would you still go the guest user plugin modification route?

@Amanda Yeah, I’d probably still go with Guest User with some modifications. The settings for it probably get at almost all of what you need. The big exception is restricting access to the public side. Adapting what it already does to restrict access to the admin side could be a simple approach.

1 Like

Hi again - just to be clear, you mean changing parameters via hookDefineAcl within the main plugin file, based on the define_acl functionality right?

I’m also still lost on how I would “hide” all Omeka content to any user.

Editing to ask: would it be easier or make more sense to set up another level for items between public and private instead?

Yes, it seems like the define_acl stuff is the way to go, at least as far as I grasp the needs. I can see a possibility that you could get around using it, though, depending on the details of the specs, related to your second question

For hiding content, I’m thinking of a change to the libraries/GuestUser_ControllerPlugin.php file. That intercepts all the requests, and lets you make early decisions about access. The _preventAdminAccess function is what prevents guest users from getting to the admin side. You could modify that to prevent access to anything if a user is not logged in, and maybe similarly redirect to what you want to get people to log in.

Setting up an intermediate level between public and private sounds very tricky. The database tables have just a public true/false flag on them, so trying to do anything more nuanced than that boolean would involve a ton of fancy footwork with permissions checks and new tables to work around that setting. I’d fear to tread there.

1 Like

Ah I had not even checked the libraries folder (d’oh!). That makes a lot more sense. I’ll work on that. Thanks.

ControllerPlugin files like that are rarely needed, so it’s definitely a deep dive into Omeka and Zend stuff!

Hmmm. Clearly I need to spend more time with this next week. I started to set something up but I can’t seem to get the getRedirect()->gotoURL to work to redirect to /users/login, i.e. (WEB_ROOT .’/users/login’). But maybe I’m missing a step…

I am not sure I am setting this up correctly. I’ve changed the ControllerPlugin in libraries as such:

 public function preDispatch(Zend_Controller_Request_Abstract $request)
    {
        $this->_preventSiteAccess($request);
        $this->_preventAdminAccess($request);
        $this->_warnUnconfirmedUsers($request);
    }
   protected function _preventSiteAccess($request)
    {
        $user = current_user();
        // prevent access to site for anyone not logged in, including guests.
        if (!$user){ 
           $this->_getRedirect()->gotoUrl(WEB_ROOT .'/login');
        }
        
    }

But it’s not working. I also tried if ($user == null) and that didn’t seem to work either. Am I missing something obvious or is this a redirect problem?

I’m getting the browser being mad about “Too many redirects”. Is that the same with you?

1 Like

So, I went with the redirect stuff being the issue. What I suggested basically creates a redirect loop that never ends.

Here’s a version of your _preventSiteAccess function that does the extra check for whether you are looking at the login page, so that it doesn’t also fire the redirect, by specifically checking the route to the login page and allowing it.

Like I said, it’s a deep dive. Hope it works – let me know!

    protected function _preventSiteAccess($request)
    {
        $user = current_user();
        $allowAccess = false;
        $requestParams = $request->getParams();
        if ($requestParams['controller'] == 'users' && $requestParams['action'] == 'login') {
            $allowAccess = true;
        }
        // prevent access to site for anyone not logged in, including guests.
        if (!$user && !$allowAccess){
            $this->_getRedirect()->gotoUrl(WEB_ROOT .'/users/login');
        }
    }


1 Like

It’d probably be worth overriding that page to give some info about how to log in, a link to registering, etc.

1 Like

Hi Patrick - wow, thanks for working on this! I guess you’re right, I was thinking too simplistically… this works perfectly to display the login page, so thank you! Now I just need to figure out how to link to registration and check for that as well. I am not familiar with getParams() so I’ll check there first.

It seems to me that for registration, I’d have to create another check somehow in order to redirect to the registration page - maybe by creating a link with ‘register’ and running another getParams()? Have not tried anything yet, but this is my thinking right now… will work on it.

I was thinking simplistically, too!

The getParams() function returns an array, where the controller and action keys are most important here. So, your additional check would look at those key=>values to figure out whether to give access.

1 Like

I think there’s something wrong with my logic. I’ve tried a bunch of things and it’s the end of the day, so perhaps I’m missing something. I got rid of everything I tried and just left this bit in, maybe you can tell me if my logic is wrong:

if (!$user && !$allowAccess){
         // check to see if redirect to registration page
            if (is_current_url('/users/new-user')) {
              $this->_getRedirect()->gotoUrl(WEB_ROOT .'/guest-user/user/register');
            }
        // default is login page
            else {
               $this->_getRedirect()->gotoUrl(WEB_ROOT .'/users/login');
            }
        }

I don’t quite know what is_current_url should be returning, and I’m pretty certain I am not using it correctly here. But the main idea is to have some kind of check to see whether or not a user has reached the login page already and chosen the “Register” link (which I’ve temporarily linked as /users/new-user in login.php). If they’re chosen that link from login.php, then I want them to be redirected to the registration page. I thought that the is_current_url would be a quick solution…