EPrints Technical Mailing List Archive
See the EPrints wiki for instructions on how to join this mailing list and related information.
Message: #05468
< 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: Andrew Collington <a.p.collington@sussex.ac.uk>
- Date: Mon, 7 Mar 2016 11:06:12 +0000
Hi John, Just wanted to say many thanks – I just tried out your snippet and it worked like a charm! Cheers, Andy From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of John Salter Hi Andrew, I missed out an important logic test in my last example. I didn’t check whether there was a user or not. This is what should have been there. I’d possibly look at extending this to check whether the user has permission to edit the EPrint too – so you only render the link to
someone who can! $c->{dynamic_template}->{function} = sub { my( $repository, $parts ) = @_;
if( $repository->current_user && $repository->{request}->pnotes( "eprint" ) ){ my $eprint = $repository->{request}->pnotes( "eprint" ); my $admin_link = $repository->render_link( $eprint->get_control_url ); $admin_link->appendChild( $repository->make_text( "Edit this EPrint" ) ); $parts->{admin_link} = $admin_link; } }; I’ve installed this on DemoPrints (http://demoprints.eprints.org/). If you view
http://demoprints.eprints.org/1/ you shouldn’t see an ‘Edit this EPrint’ link beneath the H1 title. If you create a user account, login and then view the same page, it should (magically :o) appear! NB I’m not sure how often DemoPrints is reset. When it gets reset, this will stop working! Cheers, John From:
eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of Andrew Collington Hi, No need to apologise for slightly hijacking the discussion, Alan! I’m very new to ePrints so this is actually all really helpful!
It’s good to see how others would solve the issues, if there’s a “best practices” way or not, and so on. I appreciate that the js version doesn’t fail-safe, but I was just living with the fact that the admin link shows now anyway, so if
it continues to show then “oh well”, else if it could be hidden then all the better. John; thanks for the pin code. I did actually try something in the dynamic template, but it didn’t use the pnotes method (I’ll have
to investigate that one) and I added the pin to the citation xml document rather than the default template. Given the way I did things it resulted in it not working because of the static cache build. But I will give that a shot next week and see how it goes. Thanks also, Martin, for the heads-up of the $STAFF_ONLY variable – that could come in handy! Much appreciated, all! Andy From:
eprints-tech-bounces@ecs.soton.ac.uk
[mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of Alan.Stiles The problem with hide by default is that it doesn’t ‘fail-safe’ – i.e. no JS, no visible buttons. Having them hidden but present for
crawlers is surely no worse than the current situation of always visible? I’m working on the principle that the object of the exercise is to prevent everyday users from seeing and clicking on buttons that
don’t work for them – maybe Andrew could clarify? I do like the concept of generating the abstract pages without the Staff links for general browsing purposes but checking the request
to see if you have a logged in admin user and redirecting them to a version of the page (generated on demand or with an alternate template?) with the buttons available. This seems lighter-weight than just generating the abstract fresh for each request? I suppose it depends how complicated a solution Andrew has the time / capacity to develop
(Apologies to Andrew if we’ve slightly hi-jacked the discussion!) Alan From:
eprints-tech-bounces@ecs.soton.ac.uk
[mailto:eprints-tech-bounces@ecs.soton.ac.uk]
On Behalf Of John Salter 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>
- Re: [EP-tech] Antwort: Access user via javascript?
- From: John Salter <J.Salter@leeds.ac.uk>
- Re: [EP-tech] Antwort: Access user via javascript?
- From: "Alan.Stiles" <alan.stiles@open.ac.uk>
- Re: [EP-tech] Antwort: Access user via javascript?
- From: Andrew Collington <a.p.collington@sussex.ac.uk>
- Re: [EP-tech] Antwort: Access user via javascript?
- From: John Salter <J.Salter@leeds.ac.uk>
- [EP-tech] Access user via javascript?
- Prev by Date: Re: [EP-tech] select and mysql 5.6.27
- Next by Date: Re: [EP-tech] Re-index
- Previous by thread: Re: [EP-tech] Antwort: Access user via javascript?
- Next by thread: [EP-tech] OR2016 Technical Track Submissions Close 7th March Midnight
- Index(es):