I have a deal breaker kind of question. Can Scripto (i.e. MediaWiki) be password-protected even for viewing and still be accessed by/work with Omeka (classic)? Because I notice that if I navigate to the MediaWiki install on our server, which is outside the scope of the Omeka install, that I can click on “Random page” and see the transcriptions. I think if this is impossible within the current framework, then we can’t use the tool because we are having to password-protect our site right now.
MediaWiki includes within itself support for restricting viewing of pages to authenticated MediaWiki users. Have you tried that? Coupled with restricting account creation (also described on that same page if you haven’t done so already) I would think that would be sufficient access control.
Otherwise, I suspect that “password protection” in the sense of requiring an HTTP authentication would be problematic for Scripto, but even then you could probably (for example) allow passwordless access from localhost and still accomplish what you want.
1 Like
Thanks, that works on blocking the pages from public view, but now I guess it seems like users would have to separately register a MediaWiki account, and I’m not sure how ideal that is given our user base (I had forgotten that we had discussed this a long time ago and decided against accounts just to be able to read the pages).
EDIT: So, it appears that if one blocks access to view pages (anonymous viewing), then this also blocks anonymous account creation. I added the link to LocalSettings.php per the MediaWiki instructions, but then I can never get to the account creation page on MediaWiki. I can access the Login page, which seems to me to suggest I would need to set up every user account (not going to happen). Obviously, once I remove the line from LocalSettings, the account creation page is again accessible, but so are all the page contents.
So I realize this is on the MediaWiki side, but there seems no way around the issue without allowing full anonymity.
Sorry to bring this up again, but we’ve decided we want to do the following:
Transcriptions can be viewed by anyone, but only edited by a registered user in mediawiki. So, I created a registered user and added the following line to my mediawiki LocalSettings.php:
$wgGroupPermissions['*']['edit'] = false;
The result is that I can’t edit the wiki page unless I am logged on as the appropriate mediawiki user, but when I go to the item in Omeka, using this user, I get the following message:
“You don’t have permission to transcribe this page.”
So, I try to “Login to Scripto” from within Omeka a variety of ways (within an item, from the Scripto public page, from Script admin side, all using the same user that I just created) and yet, even though it says I’m now logged in, I navigate back to the item page and still keep getting this same message. Am I missing something?
Also, we’re running Omeka 2.6.1, MediaWiki 1.30 and Scripto 2.3
Did you add a “MediaWiki cookie prefix” in Scripto plugin configuration? A missing MW cookie prefix is usually the reason why you’d simultaneously see “Successfully logged into Scripto” and “Log in to Scripto”.
I think you’re right, that’s the issue… What happened was that I had to dump and reinstall MediaWiki somewhere along the way, and somehow the prefixes were changed (probably my fault at the initial install). When looking at the LocalSettings.php file, the DBname is “my_wiki” and the DBprefix is “omeka_wiki” (and the mysql tables now look funny with that prefix and no underscore between). At any rate, does this mean that I should put “my_wiki_omeka_wiki” for the MediaWiki cookie prefix? Or do I need an underscore, i.e. “my_wiki_omeka_wiki_”?
EDIT: it works without the underscore, as predicted based on MySQL table names… good for now. Thanks for pointing this out!
This topic was automatically closed after 250 days. New replies are no longer allowed.