Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
developers_call:minutes20120821 [2012/08/21 14:28] – demiankatz | developers_call:minutes20120821 [2012/08/21 14:48] – demiankatz |
---|
==== 4. Open Data / Shared Central Index ==== | ==== 4. Open Data / Shared Central Index ==== |
| |
Filipe has added an entry for [[..:open_data_sources#springeropen_oai_-_pubmed_format|SpringerOpen]]. | Filipe has added an entry for [[..:open_data_sources#springeropen_oai_-_pubmed_format|SpringerOpen]]. He next plans to investigate settings for importing from InTech Open, an eBook provider. |
| |
==== 5. Other Topics? ==== | ==== 5. Other Topics? ==== |
| |
Al brought up the subject of LibX causing COinS to display awkwardly. Demian has adjusted the trunk to give COinS spans a display:none property -- this should prevent them from appearing when LibX is installed without breaking Zotero, etc. It's an easy fix to apply to an existing install (just add a couple lines to CSS) if necessary. | Al brought up the subject of LibX causing COinS to display awkwardly. Demian has adjusted the trunk to give COinS spans a display:none property -- this should prevent them from appearing when LibX is installed without breaking Zotero, etc. It's an easy fix to apply to an existing install (just add a couple lines to CSS) if necessary. |
| |
| Filipe has been brainstorming a "remember me" solution for VuFind's login system. He would like to find a way to uniquely identify a remote machine without using cookies for cross-browser memory. However, this would seem to require generation of a key on the client, which would require extra components (i.e. a Java element) and could still be spoofed. It would also be very dangerous in combination with public terminals. There was also discussion of multi-level authentication (i.e. remember the user for "safe" actions but require reauthentication for "dangerous" actions... with configuration for defining what is safe and what is dangerous). |
| |
| Demian's recommendation: implement with cookies for now (the most common practice in this area) but make the long-term authentication mechanism configurable so the cookie check can be replaced with something else if we devise a more clever mechanism for identifying users. |
| |
| Everyone agrees that this system should be optional -- not everyone will want it, and in some cases it will cause problems (i.e. in combination with single sign-on). |
| |
===== Next Call ===== | ===== Next Call ===== |