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.
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.
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.
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.
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?
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');
}
}
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.
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.
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ā¦