Bug #5868

Problems with institution-specific user accounts in 2.x

Added by Tim Hutchinson over 8 years ago. Updated over 8 years ago.

Status:VerifiedStart date:10/25/2013
Priority:CriticalDue date:
Assignee:Dan Gillean% Done:

0%

Category:Access Control
Target version:Release 2.0.1
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

In 2.x, accounts with permissions on a single repository encounter an internal server error on:
- information object browse
- digital object browse

The error (via debug mode) is:
500 | Internal Server Error | Elastica\Exception\InvalidException
Invalid parameter. Has to be array or instance of Elastica\Filter

Let me know if you need the stack trace or other details. I'm not sure how to determine what arguments are being passed.

Also, when logged in as an institutional user, browsing places and subjects is noticeably slow compared to unauthenticated or admin. With our photograph database (78,000+ information objects), it's timing out.

To reproduce:

RepositoryAccount_StackTrace.htm Magnifier (106 KB) Tim Hutchinson, 10/25/2013 10:22 AM

History

#1 Updated by Dan Gillean over 8 years ago

  • Category set to Access Control
  • Assignee set to Jesús García Crespo
  • Priority changed from Medium to High
  • Target version set to Release 2.0.1

Hi Tim,

Thanks for finding this. We've noted a few issues with the access controls that we hope to fix soon, but this is a pretty critical one. A stack trace would be very useful - if you could save it as an HTML file and attach it, that's the most useful way to append it to the issue ticket. Thanks!

#2 Updated by Tim Hutchinson over 8 years ago

Here you go. Hope this works - I changed the server name and internal paths to generic values.

#3 Updated by Tim Hutchinson over 8 years ago

A bit more about this... If you add the user to (e.g.) the editor group, you can browse the information objects, but linking to an individual information object times out (again, in the large 78,000+ db)

#4 Updated by Tim Hutchinson over 8 years ago

Also, I will flag here that the 2.x documentation should be updated to indicate that the user should not be in the contributor or editor group (this is correct in the 1.3 documentation). I don't think this is obvious, since the instructions are in the section about editing existing users.

https://www.accesstomemory.org/en/docs/2.0/user-manual/administer/edit-permissions/#edit-archival-institution-permissions-by-user
After point 3, something like:
4. First make sure that the user is not assigned to a user group e.g. contributor or editor. Leave this blank and the user will be automatically assigned to the parent group of authenticated (which is all users who have successfully logged in).

#5 Updated by Tim Hutchinson over 8 years ago

As for the 1.3.1 timeout issue, this boils down to viewDraft - if that is set to inherited rather than grant (at the institution level), the error isn't raised.

#6 Updated by Dan Gillean over 8 years ago

Thanks for all the detailed notes, Tim. I've got a wonderful intern helping with the docs who has been working on that page. I've forwarded her the issue ticket to take a look, test, and update the documentation accordingly.

#7 Updated by David Juhasz over 8 years ago

  • Priority changed from High to Critical

#8 Updated by David Juhasz over 8 years ago

  • Assignee changed from Jesús García Crespo to Mike Gale

#9 Updated by Mike Gale over 8 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Mike Gale to Dan Gillean

Hey Dan, can you confirm that these permissions work, and that nothing else broke permissions-wise that is easy to check?

Here's the AtoM instance with the fix on it:
http://192.168.1.201/issue5868

/ demo is the administrator account
/ test is the test account I used to see if setting archival description permissions by institution would crash AtoM when the user is logged in and tries to browse archival descriptions.

Right now there are 2 repos in the test data: "institution 1" and "other institution", both of which have 2 archival descriptions each (one published one draft). Test should have access to view the draft from institution 1, and AtoM (obviously) shouldn't be crashing anymore ;)

Cheers

#10 Updated by Dan Gillean over 8 years ago

  • Status changed from QA/Review to Verified

I've tested this with a new user and a new repo to be sure - and I tested both repo permissions per institution, and archival description permissions per institution. Everything appears to be working! Marking verified.

#11 Updated by Tim Hutchinson over 8 years ago

Hi guys,
I wanted to remind you that part of the original report was that I experienced a timeout on a few pages. In fact even our smaller database (approx. 5000 records), browsing places and subjects (also archival descriptions via the "what's popular" block) is noticeably slower when viewDraft is set at the institution level - and there are only 6 places in that database. The AC beta data should be plenty large to see whether the other changes have dealt with that.

If you want a larger data set to test the actual timeout, I can send you a dump of ours (approx. 78,000 records), or I should be able to test later this week or early next week, depending when our test site can be updated.

#12 Updated by Dan Gillean over 8 years ago

Hi Tim,

We tested this issue on a separate branch without much data - it has definitely resolved issues with permissions. Now that we know the patch is stable and doesn't appear to be breaking anything else, I've asked Mike to apply it to our main development branch, where I can test it against the AC data. If I can reproduce the performance hits you've described, we'll reopen the issue and see if we can find the cause and improve the situation. If you do some independent testing on your own site and try to reproduce the conditions under which you first reported, that will also give us more insight. But yes, we'll follow up on this aspect of the issue now. Thanks.

#13 Updated by Tim Hutchinson over 8 years ago

Hi Dan,

Sounds good. From earlier testing before I posted yesterday, to try to reproduce it, you need to ensure that viewDraft is set to grant under the individual institution; and to inherit for all archival descriptions. If you can't reproduce, it let me know - it occurs to me that there may not be any draft records in the AC data (at least the beta site).

Also available in: Atom PDF