Now that you have the option to log-in to Copac to use the personalisation features, here are some tips to make logging in as easy as possible.
Typekey/Typepad: if you have a Typekey or Typepad account, and were wondering where your login option was, worry no longer! From the drop-down list of organisations on the login page, you need to choose ‘JISC project: SDSS (TypeKey Bridge)’. It’s not immediately obvious, but it is the correct login option for any TypeKey users.
Navigating the list: the list of organisations is very long, and weighted heavily towards ‘U’. To navigate it more easily, you can jump straight to any letter by typing it on your keyboard. You may find it even easier to enter a keyword search in the search box. This will work for partial words as well – entering ‘bris’ will give you the options of the City of Bristol College and the University of Bristol.
Remembering your selection: once you have found your organisation, there are options to have your selection remembered, either for that session (the default) or for a week. You can also choose ‘do not remember’, which is especially useful if you are on a public computer.
Please contact us if you experience any problems with logging in to Copac.
Users from some Institutions had been unable to login in Copac Beta. Thanks to help fromÂ colleaguesÂ we think we have now resolved the issue which was related to an exchange of security certificates between servers. The result was that a handful of InstitutionsÂ were not trusting us and so were not releasing the anonymised username that we require. This seems to be fixed now and we’ve noticed that users from those Institutions can now login.
So, if you tried to login to Copac Beta and received a “Login failed” message, please try again. And please let us know if you still can’t get access.
The Search History and My References feeatures of the Copac Beta TestÂ Interface are stored in a database with an Atom Publishing Protocol (APP) Interface. The idea is to make the database open to use by otherÂ people and services and so enable re-purposing of the data.
Authentication poses a problem. We need to authenticate so that weÂ can identify the user and show them their records and not someoneÂ elses. We didn’t want people to have to register to use Copac andÂ neither did we want to get into developing a mechanism to handle userÂ registration, etc. So, we have used the JISC supported UK Federation (aka Shibboleth) Access Management system. This allows users to loginÂ to Copac using their own instiutional username. Registering separatelyÂ with Copac is not needed to gain access.
So, can we make do without Shibboleth? Well we can, but the optionsÂ are either not terribly insecure or not practical. The options I canÂ think of are:
- We put a token (eg a unique id) in the url. This effectively makesÂ the users collection of records and search history public if the urlÂ is published.
- We put the token in a cookie. This is still insecureÂ and subject to cookie highjacking, but is more private as the tokenÂ isn’t in the url. Many high profile web sites seem to use such anÂ cookie for authentication, and if they do, then I don’t seeÂ why we shouldn’t? However, I’m not sure how practical it is to getÂ third party APP clinet software to send the cookie â€” unless the APPÂ client was written as part of a web browser that already has theÂ cookie.
You can try accessing the Shbboleth protected APP server for yourself atÂ the following url:
If you’ve already used the Copac Beta then your Search History and MyÂ References collections can be found at the following urls in the form of Atom feeds:
Please let us know how you get on! I’ve tried the above urls with Firefox and Safari. Firefox getsÂ through the authentication and displays the Atom feeds and Service Documents. Safari seemsÂ to put itself into an infinite loop whilst trying to display the feedÂ (maybe this is something to do with the XML in our Atom feed?)
We’d be very interested to hear your thoughts on the above.