EPrints Technical Mailing List Archive
Message: #05454
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
Re: [EP-tech] Antwort: Access user via javascript?
- To: "'eprints-tech@ecs.soton.ac.uk'" <eprints-tech@ecs.soton.ac.uk>
- Subject: Re: [EP-tech] Antwort: Access user via javascript?
- From: John Salter <J.Salter@leeds.ac.uk>
- Date: Fri, 4 Mar 2016 10:04:06 +0000
Here’s my though for the best route… this is a slightly more difficult nut to crack than it first seems. You could have the links rendered in the page, hidden by default, and reveal them with a bit of _javascript_/a css rule applied when
there’s a logged-in ‘staff’ user. Whilst this works, in my mind it’s a bit ‘hacky’ – the links are still present in a page where you don’t want them – a crawler can
still find them. As the page being served is a cached copy, there isn’t the same access to the EPrint object that you’d have in e.g. an EPrint::View
screen – so adding a link to the toolbar / template isn’t straightforward either. My two suggestions are: 1.
Use a Screen plugin that checks the URL if the request – trying to match ^(\d+)\D?$ as the EPrint ID 2.
Use a Screen plugin that access the Apache request, and looks for $r->pnotes( “eprint” ); or possibly $r->pnotes( “eprintid”
); and render the control URL from the EPrint object. I think the second of these *might* be the best solution, but I’m not sure what the performance impact would be. Anyone have any thoughts on these options? Cheers, John From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of Alan.Stiles The issue doesn’t seem so much one of security (the standard access control on eprints will still stop unauthorised users from accessing
staff only areas) but rather one of hiding the buttons from those who don’t require them in the pre-built static abstract pages rather than the workflow. This means that you either have to rebuild the pages every time they are requested, which is heavy on
the server, especially once there are 5 or 6 spiders farming your site, or you use some _javascript_/jquery to hide or not hide the repository admin access buttons as appropriate. It was I who suggested that idea to Andrew on the user group list, with the belief that some aspect of the user profile was available
in JS. Assuming I was wrong on that front, would the best way to get that detail dynamically be an ajax call to a cgi function to return whether or not the user was an admin and, if not, hide the buttons (possibly requiring a surrounding ‘div’ or some such
on the elements to be hidden). That way the worst that happens if the script fails or JS is disabled is that the buttons are still visible, as they are currently? Any thoughts folks? Cheers, Alan From:
eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of martin.braendle@id.uzh.ch Hi,
-- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302). The Open University is authorised and regulated by the Financial Conduct Authority.
|
- References:
- [EP-tech] Access user via javascript?
- From: Andrew Collington <a.p.collington@sussex.ac.uk>
- [EP-tech] Antwort: Access user via javascript?
- From: martin.braendle@id.uzh.ch
- Re: [EP-tech] Antwort: Access user via javascript?
- From: "Alan.Stiles" <alan.stiles@open.ac.uk>
- [EP-tech] Access user via javascript?
- Prev by Date: Re: [EP-tech] Antwort: Access user via javascript?
- Next by Date: Re: [EP-tech] Antwort: Access user via javascript?
- Previous by thread: Re: [EP-tech] Antwort: Access user via javascript?
- Next by thread: Re: [EP-tech] Antwort: Access user via javascript?
- Index(es):