IIIParse->login function

33 views
Skip to first unread message

alan

unread,
Oct 12, 2010, 10:51:26 AM10/12/10
to mobilecat
Hi,

I have been looking at this for a couple of days and have got mobile
cat part working, however I am struggling with the login function. Our
Millennium set-up is different to yours in that we require a pin, we
use an ssl login and we are on 2009b. I have made a simple change to
the function by adding a $pin variable.

What I don't understand is the check for login sucess (nothing in the
response body). When I enter valid credentials into the $login_url I
get the patrons page back - with a lot of content in the response
body. If I enter invalid credentials I get the login page back - still
with content in the response body - so it doesn't seem to be a decent
check for me. (Also there is not [Set-Cookie] key in the response-
>headers).

I have to say I am quite new to the php_http module so I could be
misreading this, when I have done this kind of login using curl I have
had to regexp the response as a check whether I am logged in. Could
you give me an indication of how the $resp objects should look for
sucess/failure.

Thanks

Alan


--snip--
public function login($name, $code, $pin) {
$query = http_build_query(array(
"name" => $name,
"code" => $code,
"pin" => $pin,
));

$login_url = $this->catalog_url . "/patroninfo/?$query";

$resp = http_parse_message(http_get($login_url));


# If there is any body in the response, we failed to login
if (strlen($resp->body) > 0) {
return null;

} else {
$cookies = cookie_strings_to_array($resp->headers['Set-
Cookie']);
$loc = $resp->headers['Location'];
return array(
"userid" => get_userid_from_patron_loc($loc),
"cookies" => $cookies,
);
}
}
.

anna headley

unread,
Oct 12, 2010, 1:48:34 PM10/12/10
to mobi...@googlegroups.com
Hi Alan,

Well, I don't know much about ssl.  Is this an option provided by III?  It might be that webpac responds differently to the two different types of logins.

The set cookies in the response we get here (I was just looking at these the other day) include SESSION_SCOPE, III_EXPT_FILE, and III_SESSION_ID.  I think the way MobileCat currently works is by saving the login/barcode and resubmitting for a new session id each time it wants to do something that requires a login.

I am poking around a little bit and, using curl, it looks like a successful login to our tripod catalog does give me a message body.  So I'm not sure how this logic came about.  I'm in the middle of some crazy but I can look into it further on Thursday.

I hope you will keep track of what you do so we can add this ssl variable into the settings file (SiteParse), and make things easier for people in the future.

Sorry I can't be more helpful right now.  I hope you'll keep us posted if you figure out anything more.

Anna
TriCollege Libraries
ahea...@swarthmore.edu

Amy Deschenes

unread,
Oct 12, 2010, 2:00:59 PM10/12/10
to mobi...@googlegroups.com
Hi All-

I just wanted to throw in that I'm interested in different login options for mobilecat as well.

At Simmons we use LDAP authentication for people to login to the catalog.  It validates against a  user's ID number, which is stored in III.

If anyone has any insights it would be great.

Thanks
Amy
--
Amy Deschenes
Library Assistant, Library Technology
Simmons College Library
Boston, MA



Dave Hansen

unread,
Oct 13, 2010, 2:07:10 PM10/13/10
to mobi...@googlegroups.com
Alan,

Is your standard catalog's successful login page at all similar to mine? Take a look at my screenshot. COuld you also copy/paste or attach a copy of the HTML from the successful login page? Your SiteParse.php could help as well.

Anna and Amy, it would be great to get the HTML from your login pages as well.

If I recall, the login page checks for a blank page because III redirects successful logins to a different page. A fail returns back to the form (without a redirect?). I tweaked around with this a bit but might be wrong, I didn't make the design decision with the blank page.

Most likely there's a similar element between this page on all catalogs. If not, I can help Alan find an appropriate selector on the success page.

Best,
Dave

Screen shot 2010-10-13 at 10.49.44 AM.png

anna headley

unread,
Oct 14, 2010, 12:07:42 PM10/14/10
to mobi...@googlegroups.com
Hey Dave,

Have you confirmed the blank page?  Since the check is working for our mobile site, the logic must be okay for us.  But my attempts to use curl and wget on the patroninfo url with querystring appear to be returning the login page with the form filled out, rather than the submitted result.

Anna


David Hansen

unread,
Oct 14, 2010, 12:43:34 PM10/14/10
to mobi...@googlegroups.com
For my library's catalog, a var_dump of $resp after http_parse_message() shows a redirect to /patroninfo~S1/... with an empty body. I'd like to see what this looks like on other catalogs. Following the redirect takes you to the page in my earlier email's screenshot.

Anna, I got the same results as you using wget. Looking at the results from wget, it was only was only passing the first item in the GET request and failing to login. Invoking  wget with the URL in quotation marks, wget returns a successful login page nearly identical to Alan's. See if that fixes it, I'm on Ubuntu 9.04 running wget 1.11.4

var_dump output:
object(stdClass)#3 (7) {
  ["type"]=>
  int(2)
  ["httpVersion"]=>
  float(1.1)
  ["responseCode"]=>
  int(302)
  ["responseStatus"]=>
  string(10) "Over There"
  ["headers"]=>
  array(9) {
    ["Date"]=>
    string(29) "Thu, 14 Oct 2010 16:30:44 GMT"
    ["Server"]=>
    string(7) "III 310"
    ["Mime-Version"]=>
    string(3) "1.0"
    ["Location"]=>
    string(25) "/patroninfo~S1/153025/top"
    ["Set-Cookie"]=>
    array(3) {
      [0]=>
      string(23) "SESSION_SCOPE=1; path=/"
      [1]=>
      string(52) "III_EXPT_FILE=aa6517; path=/; domain=.stmarys-ca.edu"
      [2]=>
      string(79) "III_SESSION_ID=21ce1b28b24ce7ae3b13d7d065095d3a; domain=.stmarys-ca.edu; path=/"
    }
    ["Vary"]=>
    string(26) "Accept-Encoding,User-Agent"
    ["Content-Type"]=>
    string(10) "text/plain"
    ["X-Original-Transfer-Encoding"]=>
    string(7) "chunked"
    ["Content-Length"]=>
    string(1) "0"
  }
  ["body"]=>
  string(0) ""
  ["parentMessage"]=>
  NULL
}

Dave
-- 
Dave Hansen
Electronic Resources Manager
dm...@stmarys-ca.edu
Saint Mary’s College of California
1928 Saint Mary’s Road
Moraga, CA 94575-4290
(925) 631-4253 x4253

alan

unread,
Oct 15, 2010, 6:12:49 AM10/15/10
to mobilecat
Anna,

Thanks for the response. SSL is an option provided by III see the
manual page no 107075. I have been messing with the login function a
bit more. What I found is that if you POST the data to the https login
page, rather than GET it, the login function works. So far using POST
rather than GET doesn't seem to have had any negative effects on other
parts of the code. Can you think of any? My modified login function is
below

--snip--
public function login($name, $code, $pin) {
$query = http_build_query(array(
"name" => $name,
"code" => $code,
"pin" => $pin
));

$login_url = $this->get_login_url() . "/patroninfo";
//$login_url = 'https://library.bury.gov.uk/patroninfo~S1';

//$resp = http_parse_message(http_get($login_url));
$resp = http_parse_message(http_post_data($login_url,
$query));
//print_r($resp);


// If there is any body in the response, we failed to login
if (strlen($resp->body) > 0) {
return null;

}
else {
$cookies = cookie_strings_to_array($resp->headers['Set-
Cookie']);
$loc = $resp->headers['Location'];
return array(
"userid" =>
get_userid_from_patron_loc($loc),
"cookies" => $cookies,
);
}
}
--snip--

I have added another function which takes the catalog url and changes
it to the secure login (get_login_url())

--snip--
protected function get_login_url() {
if(!$this->ssl) {
return $this->catalog_url;
}
else {
if (preg_match('/^http:\/\/(.+)$/', $this->catalog_url,
$matches)) {
$login = 'https://' . $matches[1];
return $login;
}
}
}
--snip--

This is based upon a boolean $ssl in Siteparse.php, so should work
with non-ssl sites as well. It would be easy to make the POST the
loging function conditional on this variable, if necessary. I have
also added a boolean $pin in Siteparse.php there as well - which I am
using to modify login.php, login-accept.php and login.html as well as
the do_logout function. I haven't generalised the login function using
this yet. I will keep you posted.

Alan

On Oct 12, 6:48 pm, anna headley <anna...@gmail.com> wrote:
> Hi Alan,
>
> Well, I don't know much about ssl.  Is this an option provided by III?  It
> might be that webpac responds differently to the two different types of
> logins.
>
> The set cookies in the response we get here (I was just looking at these the
> other day) include SESSION_SCOPE, III_EXPT_FILE, and III_SESSION_ID.  I
> think the way MobileCat currently works is by saving the login/barcode and
> resubmitting for a new session id each time it wants to do something that
> requires a login.
>
> I am poking around a little bit and, using curl, it looks like a successful
> login to our tripod catalog does give me a message body.  So I'm not sure
> how this logic came about.  I'm in the middle of some crazy but I can look
> into it further on Thursday.
>
> I hope you will keep track of what you do so we can add this ssl variable
> into the settings file (SiteParse), and make things easier for people in the
> future.
>
> Sorry I can't be more helpful right now.  I hope you'll keep us posted if
> you figure out anything more.
>
> Anna
> TriCollege Libraries
> ahead...@swarthmore.edu

alan

unread,
Oct 15, 2010, 7:01:12 AM10/15/10
to mobilecat
Actually, checking again the login function seems to work with GET on
the https: url. However but my $resp seems to be quite short in
comparsion to others particularly in the ['Set-Cookie'] area. It
appears to be causing warnings in other parts of the code.

stdClass Object
(
[type] => 2
[httpVersion] => 1.1
[responseCode] => 302
[responseStatus] => Over There
[headers] => Array
(
[Date] => Fri, 15 Oct 2010 10:47:17 GMT
[Server] => III 310
[Mime-Version] => 1.0
[Location] => /patroninfo~S1/1027894/items
[Set-Cookie] => SESSION_SCOPE=1; path=/
[Vary] => Accept-Encoding,User-Agent
[Content-Type] => text/plain
[X-Original-Transfer-Encoding] => chunked
[Content-Length] => 0
)

[body] =>
[parentMessage] =>
)

David Hansen

unread,
Oct 15, 2010, 11:44:45 AM10/15/10
to mobi...@googlegroups.com
Thanks Alan. I'll take a look at the response and your note of the
warning and get them into a new release.

For what its worth, our Albert catalog handles SSL logins just fine out
of the box. Though its always a good idea to POST instead of GET I suppose.

Dave

--

Dave Hansen
Electronic Resources Manager
dm...@stmarys-ca.edu

Saint Mary�s College of California
1928 Saint Mary�s Road

anna headley

unread,
Oct 15, 2010, 11:59:01 AM10/15/10
to mobi...@googlegroups.com
I don't think using POST makes sense.  POST is for when you want to make a change on the server / database.  All our interactions with the III opac are appropriate GET requests.

Anna


Saint Mary’s College of California
1928 Saint Mary’s Road

alan

unread,
Nov 17, 2010, 9:35:49 AM11/17/10
to mobilecat
Due to some very odd dumps that I was getting from the login process
when checking the renew function, I have rolled back to version 1.0
and re-applied my edits in a granular fashion. I also built a little
check function

$login_url = "https://library.bury.gov.uk/patroninfo";
$fields = array('name' => 'user', 'code' => 'barcode', 'pin' =>
'pin');
$query = http_build_query($fields);
//$resp = http_parse_message(http_get($login_url . "?$query"));
$resp = http_parse_message(http_post_data($login_url, $query));
print strlen($resp->body);
print_r($resp);

What I have found is that when I use the http_post_data the function
works, I can change the user details and I get a new patron id back as
expected. When I use http_get, sometimes the function works (I think
when I have previously used post) and sometimes not. But what does
seem consistent is that when I have logged in once using get and put a
new users details in, the resp->header returns the patron id of the
first user. Even if I clear out cookies etc. I think the use of get
may be causing me similar problems with the renew function

On Oct 15, 3:59 pm, anna headley <anna...@gmail.com> wrote:
> I don't think using POST makes sense.  POST is for when you want to make a
> change on the server / database.  All our interactions with the III opac are
> appropriate GET requests.
>
> Anna
>
> >>>         //$login_url = 'https://library.bury.gov.uk/patroninfo~S1<https://library.bury.gov.uk/patroninfo%7ES1>
> >>> ';
> > d...@stmarys-ca.edu

alan

unread,
Jan 10, 2011, 11:15:51 AM1/10/11
to mobilecat
I think I may be getting to the bottom of my problem here - it is
possibly a poor installation of the pecl http library. When I use
Pears http library I get the III_EXPT_FILE and III_SESSION_ID cookies
that I do not get from the pecl http library. I will test by using the
pear http library for the login function, but also try looking at the
pecl http library.
> ...
>
> read more »
Reply all
Reply to author
Forward
0 new messages