Closed raducostea closed 7 years ago
@raducostea Have you made any progress on this? I am able to log into other MLS' just fine, but CRMLS is always giving me "401 Unauthorized". Any ideas?
@mikebronner not really, i just gave up and i am using the old version of the rets.
I did figure a work-around (really poor though) that works for me so far:
$rets = new Rets($retsConfig);
$rets->setLogger($log);
try {
$rets->Login();
} catch (Exception $e) {
$rets->Login();
}
To me it looks like a server issue with CRMLS (I've had trouble with their servers in the past). Your note about requiring a second attempt triggered this idea, and it seems to work.
Update: apparently that was a fluke that I could connect. Now it won't let me connect anymore. So frustrating to diagnose when its not consistent.
@troydavisson Do have any thoughts on what might be happening here? I noticed there was a closed issue on this back in 2014 that seemed to fix it for v1.
Also contemplating if this is a Guzzle Issue, as the login result shows successful, yet Guzzle triggers a 401 error. Is there a way to tell Phrets 2 to use CURL instead of guzzle?
I believe they go more into depth about the issue here: https://github.com/guzzle/guzzle/issues/1153 and PR has been submitted for Guzzle 6.1.
This is still a problem. PHRETS/2.0 requires guzzle 4 or 5, but not 6, explicitly. Even if the fix that is suspected of fixing the problem is resolved in 6.1, Troy would need to update PHRETS/2.0 to support Guzzle 6.x.
@troydavisson Any chance that will happen? Are you actively making changes to PHRETS/2.0?
Thanks @mikebronner for the work-around -- agreed it is hacky, but I suspect that a work-around could be put in place that is more clean, such as doing the login again and checking the response to GetSystemMetadata() before actually believing the exception.
I've started a new branch which changes PHRETS 2.x to support Guzzle 6+. Please try out the 2.3.x-dev
Composer version and report back with any problems you run into.
Thank you Troy.
I tried 2.3.x-dev but it didn't help either. I've narrowed it down to a missing cookie. Request is not sending the cookie with the request. It might have something to do with the Cookie jar or perhaps it's not included in the request options. I've worked heavily over the past few months with Guzzle and I've already found a few bugs in it.
Another thing I noticed is that the cookie has a path and it could be that guzzle has a bug which doesn't work properly when a path is supplied for the cookie.
Another thing I noticed is that the server is sending two "Set-Cookie" headers in the response.
@troydavisson Yup, it's seems that when doing Digest authentication through Guzzle it does not include the cookie required for some servers.
Hi those of you with the cookie problem might check this solution. (someone else's post)
Thank you for that link. I missed that post in the group.
I've pushed a change to the 2.3-dev branch which should fix this (at least temporarily until Guzzle does something different).
Version 2.3 has been released and includes some changes which should address this. Please give the latest version a try if able.
I am trying version 2.3 but still getting same issue. Anyone have found solution for this?
I am having trouble login in to a rets server and i think is something related to cookies. If i use curl command line using a cookie jar file it works (Important: if i dont use a cookie file its not working)
Here is the debug log from the phrets.
[2015-04-29 02:43:23] PHRETS.DEBUG: Loading Monolog\Logger logger [] [] [2015-04-29 02:43:23] PHRETS.DEBUG: Sending HTTP Request for https://rets.crmls.org/contact/rets/login (Login) {"cookies":true,"debug":true} []
< HTTP/1.1 401 Unauthorized < Server: Apache-Coyote/1.1 < Set-Cookie: JSESSIONID=37C5D5128B409C50F0512630F5576E38; Path=/contact < Set-Cookie: JSESSIONID=37C5D5128B409C50F0512630F5576E38; Path=/contact < MIME-Version: 1.0 < Cache-Control: private < RETS-Version: RETS/1.7.2 < WWW-Authenticate: Digest realm="rets@retsiq.com",qop="auth",nonce="a046d8c8edf907fac4c9075805c9d039", opaque="9885bba5142ce" < Content-Type: text/html;charset=utf-8 < Content-Length: 954 < Date: Wed, 29 Apr 2015 09:43:22 GMT <
< HTTP/1.1 401 Unauthorized < Server: Apache-Coyote/1.1 < Set-Cookie: JSESSIONID=1CAB2481E7B7DCD20C72E5F3CE4380F9; Path=/contact < Set-Cookie: JSESSIONID=1CAB2481E7B7DCD20C72E5F3CE4380F9; Path=/contact < MIME-Version: 1.0 < Cache-Control: private < RETS-Version: RETS/1.7.2
This is the request using curl command line and a cookie jar file.
First request
So you can actually see that the first request is missing the cookie resulting in a 401 error.