Jump to content


Photo

HTTP Authentication for XML requests


  • Please log in to reply
5 replies to this topic

#1 Lars Kneschke

Lars Kneschke

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 16 April 2012 - 10:37 AM

Hello!

We are using SNOM 320 phones running version 8.4.32. All phones received a http client username and password(http_client_user and http_client_pass) via autoprovisioning.

If they talk to our software to request a XML menu(SnomIPPhoneMenu for eaxmple), the phones always have to authenticate first. Unfortunately the phones always try first without HTTP authentication and after a HTTP 401 response with authentication. Because of this, the XML user interface is very slow as any request has to be issued 2 times.

I also tried to put the username and password directly into the url, but this did not change the behaviour. The phones still tried first without and then with authentication.

Is there any way to force the phones to send HTTP username and password already in the first request?

Lars

#2 AMH

AMH

    Expert Member

  • Members
  • PipPipPipPipPip
  • 566 posts
  • Gender:Male
  • Location:Bonn / Germany

Posted 16 April 2012 - 10:58 AM

Hi Lars,

perhaps the easier solution would be to make it work without HTTP authentication? As you seem to not mind passing the username and password in the URI like
http://thisisphone123:herpassword@yourapp.server:/xmlmenu?listing=abc
you could as well pass the authentication information as GET parameters, which would most probably get around the double requests:
http://yourapp.server:/xmlmenu?listing=abc&username=thisisphone123&password=herpassword
Using cookies might even make username tracking easier.
Besides you could - assuming PHP scripting on the server side - use the request source IP like
$request_from_ip=$_SERVER["REMOTE_ADDR"];
In many setups phones are configured to use fixed addresses - either in the phone config or the DHCP server setup, where those hardware addresses are listed for fixed addresses. Of course that would not save you from abuse (someone could plug a laptop into the phone port and give it a "phone IP address". Considering that person could then also snoop the traffic and possibly extract authentication information anyway, probably this is not really troublesome in regard of security considerations.

BTW first requesting a page without any credentials sent is "the right thing to do". Reason: There is more than one authentication scheme (plain, digest etc) and which one shall be used cannot be discovered from the URI, only from a request to the server. Sending auth data just in one of the possible methods, in case it is the right one, would work - but if the wrong scheme was used this would lead to "authentication with this moethod denied", which could probably not be distinguished from "wrong password" in a reliable way.

HTH
AMH

#3 Lars Kneschke

Lars Kneschke

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 16 April 2012 - 12:45 PM

Thanks for your response.

Sending no password first, to get a response back saying which auth type to use makes sense. And you're right, that's common practice. I just forgot it, as I did not use it for a very long time.

It seems like cookies are not supported by SNOM phones. So this is no option. Sending the username and password as GET parameter might work, but then I have all usernames and passwords in the logfiles.

I had a closer look and from my point of view, the SNOM phone takes a break after the 401 HTTP response. I see always a delay of 2...3 seconds in the access log of the webserver between the request without username and password and the authenticated one.

Bad situation.... :-(

#4 AMH

AMH

    Expert Member

  • Members
  • PipPipPipPipPip
  • 566 posts
  • Gender:Male
  • Location:Bonn / Germany

Posted 16 April 2012 - 12:54 PM

It seems like cookies are not supported by SNOM phones. So this is no option. Sending the username and password as GET parameter might work, but then I have all usernames and passwords in the logfiles.

I had a closer look and from my point of view, the SNOM phone takes a break after the 401 HTTP response. I see always a delay of 2...3 seconds in the access log of the webserver between the request without username and password and the authenticated one.

Bad situation.... :-(


Please check if you also have 2-3 seconds delay when accessing the webserver from a regular browser - if this is related to the webserver config, you might get around it there.
One more idea: (PHP) sessions can also be used without cookies, you would need to append a session id to the URI in that case. That way only the first call (from a snom button etc.) would need the authentication, then following calls like browsing the address book could rely on that session and not give the delay penalty. The first call would always go to (protected) /auth.php?goto=phonebook and the following php scripts would be unprotected but check for the existance of a valid session.

BR
AMH

#5 Lars Kneschke

Lars Kneschke

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 19 April 2012 - 11:49 AM

One more idea: (PHP) sessions can also be used without cookies, you would need to append a session id to the URI in that case. That way only the first call (from a snom button etc.) would need the authentication, then following calls like browsing the address book could rely on that session and not give the delay penalty. The first call would always go to (protected) /auth.php?goto=phonebook and the following php scripts would be unprotected but check for the existance of a valid session.


Providing the session key as GET parameter is a good idea. That solves half of the problem.

In the mean time I found the real source of the problem. The SSL handshake takes too long. The website is available via strong encryption only and it looks like the phone needs 2-3 seconds to finish the ssl handshake.

#6 AMH

AMH

    Expert Member

  • Members
  • PipPipPipPipPip
  • 566 posts
  • Gender:Male
  • Location:Bonn / Germany

Posted 19 April 2012 - 04:10 PM

Providing the session key as GET parameter is a good idea. That solves half of the problem.

In the mean time I found the real source of the problem. The SSL handshake takes too long. The website is available via strong encryption only and it looks like the phone needs 2-3 seconds to finish the ssl handshake.


Thanks for giving that feedback. As our phones are in "safe" environments, I don't care about using HTTPS too much. I will keep that problem in mind for the future.
Perhaps the 8xx series is a little faster though with the SSL handshake, so I never noticed even where I had some HTTPS going on.

BR
AMH




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users