401 unauthorized

retag add tags

Just in the last week our ability to query listings has stopped working. We have not made any changes to how we connect or query and it had been working without a hitch for 3 years up until 12/2/18.

Our connection url is: http://tsierra-rets.paragonrels.com/r... We also have a connection to http://nnrmls.rets.paragonrels.com/re... that is also started to fail at the same time.

Our account name is

We had been using Basic authentication, was this connection changed to only allow Digest authentication method now? If so, why were we not notified of this change.

We also tried authenticating to the url via Digest and we are still unable to successfully connect that way as well. There is no www-authenticate key being sent back to us in order for us to set the auth header to allow the session to be authenticated.

Are you able to at least roll back to the paragon server config/settings prior to 12/2 to get this back to original working status while being able to troubleshoot the current issue?

We service hundreds of clients that are currently impacted by this downtime.

sdbx

asked 2018-12-12 19:10:36 -0500

edit flag offensive 0 remove flag close merge delete

Comments

To be able to help I need the account name (NO PASSWORDS) for both accounts.

bwolven (2018-12-13 08:43:06 -0500) edit

I'm Sue Ruane, the AE at TSierra - Account name: SDBX Studion-RETS, Craig Tran is the user. I just got another e-mail from Account name: Tristan Roberts, getting same error. Can you help?

SURU (2018-12-13 12:03:23 -0500) edit

We are having the same problem.... it December 5th was our last successful connection to retrieve data.

cwbrmls (2018-12-13 13:34:47 -0500) edit

Can you test to see if this is back working now and comment this answer?

bwolven (2018-12-13 14:37:11 -0500) edit

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

Hi there, so we were able to resolve the issue on our end. After perusing some of the related threads, we ended up switching up to Digest authentication and also changing to use the HTTPS version of the URL. Also the cookie session variable that was being passed back to us from your feed may have been the culprit as the value appears to now be different than before. As indicated from this answered thread: http://vendorsupport.paragonrels.com/...

we isolated the specific RETS-session-ID string from what was being sent back in the cookie variable and set that as the cookie session variable on our HTTP client making the RETS query calls. Your Digest implementation however appears to be different than other MLS vendors/providers. Usually we expect a response hash variable to be sent back to us when authenticating containing a "www-authenticate" variable that we use to set on our HTTP client auth header as the signature to allow authorized requests on the data. Do you know why you do not send back this in your digest implementation?

sdbx

answered 2018-12-13 17:40:15 -0500

edit flag offensive 0 remove flag delete link

Comments

We were sending back extra cookies in addition to RETS-Session-ID.
Some clients weren't parsing them properly and it was causing errors and that was fixed today.
Also, with HTTPS we require Basic authentication and HTTP uses Digest authentication.

bwolven (2018-12-13 17:43:36 -0500) edit

Is the HTTPS requirement for Basic a new requirement? We had been successfully using Basic with standard HTTP. Also for Digest do you guys send back a www-authenticate, I didn’t see any anywhere.

sdbx (2018-12-13 18:07:23 -0500) edit

If I login HTTP I get back: WWW-Authenticate: Digest ...
If I login HTTPS I get back: WWW-Authenticate: Basic ...
It could be that your client is handling it automatically similar to what browsers do.
When I look in fiddler I see two logins, the first fails and returns WWW-Authenticate.
The second succeeds.

bwolven (2018-12-13 18:23:05 -0500) edit

add a comment see more comments

401 unauthorized edit

Comments

1 Answer

Comments