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

 

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

 

 

 

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

 

 

 

Hi,

from a point of view of security, I don't think that _javascript_ is a good way, since it can be turned off or changed browser side.

There is the undocument variable $STAFF_ONLY that can be used in EPScript und EPrints Control Format (EPC).

<epc:if test="$STAFF_ONLY = 'TRUE'">display something here</epc:if>

It is mentioned in http://wiki.eprints.org/w/How_to_control_eprint_workflow_based_on_a_user_field (in the workflow description at the bottom), but not explained there.

In my opinion, that variable (and possible other system variables) should be documented in

http://wiki.eprints.org/w/EPScript

Best regards,

Martin

--
Dr. Martin Brändle
Zentrale Informatik
Universität Zürich
Stampfenbachstr. 73
CH-8006 Zürich


Andrew Collington ---01/03/2016 14:16:18---Hi all, Is there something set up in ePrints that allows you to get user details (such as type/role,

Von: Andrew Collington <a.p.collington@sussex.ac.uk>
An: "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
Datum: 01/03/2016 14:16
Betreff: [EP-tech] Access user via _javascript_?
Gesendet von: eprints-tech-bounces@ecs.soton.ac.uk

Hi all,
 
Is there something set up in ePrints that allows you to get user details (such as type/role, email, etc.) via _javascript_?  I did have a look through the auto.js file but didn’t see anything, though given the size of that file it’d be very easy for me to miss something obvious!
 
The reason I ask is that I want to show a section in the abstract details only to admins (which is currently set up in cfg/citations/eprint/control.xml).  I originally tried to modify that section, but with the caching it obviously didn’t work.  I then tried to use a pin but had the same problems.  Someone responded to my original EPrints UK User Group post (https://groups.google.com/forum/#!topic/eprints-uk-user-group/LloconUdLDg) suggesting that js may be a good way forward.
 
If there’s not something already available then I could update the main template to include a json object of the user details which I can then use later on in the page.  But hopefully someone else has already tried to add/show content dynamically based on role (or any other user property, I imagine) and can give some advice.
 
Many thanks,
 
Andy
 
--
Andrew Collington
Web Programmer, ITS Client Services
ITS-CS Shawcross, University of Sussex, Falmer, Brighton, BN1 9QT

T: (01273) 872591 (ext. 2591)
E: a.p.collington@sussex.ac.uk
 *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

-- 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.