Patch for handling credentials (user/password)
schildi - June 19, 2009 - 11:30
| Project: | Z39.50/SRU Client |
| Version: | 5.x-1.0 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
The access to a lot of Z39.50 services need passing user/paswword even when these are public. These credentials were not supported in the current release.
Attached is a patch to the current (2008) version which hopefully solves the problem.
To do: Actually the list of servers shown in the search tab contains the credentials for each server entry. This should probably be avoided.
| Attachment | Size |
|---|---|
| z3950.module-credentials2.patch | 3.54 KB |
#1
schildi, could you please upload your latest version of your patch to the other open issue about authentication? I'd like to mark this as a duplicate.
#2
Some weeks ago I worked a bit on this module.
So, before offering my actual version I should have a look on it again.
I will try to check it on weekend.
#3
Great - I'm focusing on developing the 6.x branch, so I'm not sure when this will get applied to 5.x.
#4
please wait!
I tried to separate the API from the GUI and therefore made a couple of changes and as a result there is now some kind of submodule.
The submodule contains the functions presenting the user a list of available servers ...
The API holds the functions querying the server and getting responses.
I was struggling a bit with the list of servers and storing it in the form.
And I also have no clue how the different syntax forms (traffic with servers) are handled.
Need your held there.
I also changed the way storing metadata for servers. A new content type was set up using CCK fields.
Hopefully I will prepare a (more or less) running version of the module and append it as attachment next days. But for sure the state will be "in between".
In a discussion I got the request to have Z39.50 to help people in correcting/creating bibliographic records. That means that it should be possible to easily get data into fields of module "biblio" (copy /paste?). My work is intended to be a step in this direction.
#5
Doing this might fundamentally change the underling design in the module, which isn't something I had planned on doing. Put together a patch and I'll look it over. As far as using this module to create nodes in Drupal, this is something else that I haven't planned on incorporating directly into the module yet either (see #284748: How to save search results? for more info). There seems to be interest in this, but my guess is that different people will want to implement this differently in each case.
#6
... that different people will want to implement this differently in each case
yes. And therefor it looks meaningful to me to separate the UI from the rest of the functionality.