We are receiving a 401 - Unauthorized error in trying to access the following RETS account: mkt13ad3r. Please let us know if there is something that we can do in order to remedy this issue. Thank you for your help!
Hey, I got it to work by stripping the HTTP cookie returned from server to just the RETS-Session-ID!
Were the cookies being returned differently than before?
Yup, they were.
So I see where we are sending back multiple cookies now.
Does it fail if you send all the cookies back?
Or were you just sending the wrong one back?
It just had to do with the content of the cookie, we were just expecting the RETS-Session-ID and nothing else.
Ok. So it works if you send all the cookies that you receive back.
I just wanted to make sure it didn't break in that case.
Otherwise we would need to do a code fix.
Our work around seems to be ok.
Great.
By the way your "MarketLeader" application is still trying to search LS_6 class and is failing because your profile doesn't allow access to that class.
If you can fix that it would be helpful.
Comments
What is your RETS Login URL?
We are using the following URL:
https://cren-rets.paragonrels.com/ret...
It is probably the authentication method being used.
With HTTPS we require Basic authentication and HTTP we require Digest.
We prefer vendors to use HTTPS wherever possible.
But if that doesn't work, change the new URL to HTTP and try.
We don’t think that’s the problem. I get a 401 with or without the HTTP. Also there are other MLSs we have that use the exact same RETS/1.7.2 Black Knight solution where we don’t experience this problem.
For example, this login URL for cren returns a 401 with or without the https:
https://cren-rets.paragonrels.com/ret...
…but using the exact same login methodology (and simply substituting the credentials) with this URL for Georgia MLS:
https://gamls-rets.paragonrels.co
From our logs it looks like you are pulling data without issue.
The only exception is the LS_6 class search that is failing because you don't have access.
Can you verify that it is working now?
No, we are still encountering issues with the 401 error message. Could this be possible because this account is logged into multiple times from various IP addresses? Are you blocking one of the following IP addresses: CWS Primary Server: 207.38.102.16 CWS Secondary Server: 207.38.102.83
I only see requests from: 207.38.102.16, 199.87.168.136, and 199.87.168.145 in our logs
Did you update the URL to the new one in all of your environments?
I see requests from that account from User-Agent: "Wrecks/1.0" the 207 IP and "MarketLeader" the 199 IPs.
I'm not seeing any searches from "Wrecks/1.0" only Login attempts.
If the IP was being blocked, you wouldn't get 401 it would be a 500 error or something like that.
This is the login URL: https://cren-rets.paragonrels.com/ret...
But we don't have trouble logging in...a search returns a 401. We have the same problem with NNRMLS & CARMLS. There are 66 other downloads we run (using the same software) where we don't have this problem. The format of those logins looks mostly like these examples:
http://columbiasc.rets.paragonrels.co... http://freeport.rets.fnismls.com/rets...
But you still have the same issue if you connect using HTTP instead of HTTPS?
What library are you using to connect?
yes. we have our own RETS client.
Does the MarketLeader application use the same client?
No. But we don't have this issue with the 66 other paragon feeds, just these 3. That's why I am doubtful it is the client.
I just something interesting with this one: http://ncwv.rets.paragonrels.com/rets... Our process downloaded the data fine, but then it ran again soon after and got this error: "Server Temporarily Disabled. RETS is unavailable."
That error is normal. It is displayed when a RETS refresh is in process.
What MLS are you having the 401 issue?
You mentioned CREN and NNRMLS but what is the other one?
CARMLS...and that's it. The other 66 paragon downloads all work perfectly.
sorry, early Wednesday morning.
I'll have to do further analysis.
The environment that those 3 are on has a newer code release than the rest.
There may be a slight change in behavior with the new code.
Your initial question didn't mention anything about search getting the 401.
Because of that, I assumed you were getting the 401 during login.
You didn't mention that login was working and search was failing until today.
So I was looking down the wrong path.
Sorry about that, it was somebody less technical who originally started the thread. But what you say makes sense. I suspect the new code is somehow dropping our session perhaps.