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

 

 

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

 

 

 

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.