[ List Archives Home ] [ Thread index for 2008 ]
[ Date index for 2008 ]
[ Author index for 2008 ]
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
When we implemented wam at Leeds, we made the decision to alias our wam
service to a different name to allow for future extensibility. I.e. our
opac server lib.leeds.ac.uk is aliased to wam.leeds.ac.uk so that an
opac link looks like
http://lib.leeds.ac.uk and a wam link looks like
http://0-proquest.umi.com.wam.leeds.ac.uk/login/ipauto. We now wish to
implement SSL, but III allow only a single certificate in their https
implementation. I.e. we cannot have one certificate for lib.leeds.ac.uk
for ssl patroninfo logins and a second ceritificate for wam logins.
I see two possible solutions:
1) We change our wam server to be lib.leeds.ac.uk and change all our wam
links to be of the format proquest.umi.com.lib.leeds.ac.uk/login/ipauto.
The problem with this is that there will be a lot of links that we don't
control (eg in the vle, on departmental pages, in training materials).
2) We change our wam server to be lib.leeds.ac.uk. Set up a separate
virutal server on our main webserver and alias it to wam.leeds.ac.uk.
This could run a script that would re-format wam.leeds.ac.uk links to
work on lib.leeds.ac.uk and redirect them to lib.leeds.ac.uk. It could
also include an ip check and send on-campus users directly to the
resource (de-wamifying the url on the way) thus lessening the load on
our server. It could also be used in conjunction with solution 1,
redirecting the links we have no control over.
Has anybody had to solve this problem before who may have additional
suggestions?
Thanks, Bill Jupp,
Libarary Systems, Leeds University