Hi,

I know this is not eaxctly the right forum, but WinHTTP forum looks like 
dead.  So, I am wondering maybe somebody knows the answer here...

Why WinHTTP does not re-use Authorization obtained on the previous request, 
if the next request uses the same hInternet/hConnect handles, as it happens 
with cookies?

Why it is not possible to retrieve Authorization header from the list of 
sent headers?
Or it is possible?

The problem is that I need to make chained calls to the same server without 
re-login every time (server treats every login as a new session).  It works, 
I guess in IE and WinInternet.  Why it doesn't in WinHTTP?

Thank you.

http://msdn2.microsoft.com/en-us/library/aa383144.aspx


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Feb 28, 6:58 pm, InsDivision_6
 wrote:
> Hi,
>
> I know this is not eaxctly the right forum, but WinHTTP forum looks like
> dead.  So, I am wondering maybe somebody knows the answer here...
>
> Why WinHTTP does not re-use Authorization obtained on the previous request,
> if the next request uses the same hInternet/hConnect handles, as it happens
> with cookies?
>
> Why it is not possible to retrieve Authorization header from the list of
> sent headers?
> Or it is possible?
>
> The problem is that I need to make chained calls to the same server without
> re-login every time (server treats every login as a new session).  It works,
> I guess in IE and WinInternet.  Why it doesn't in WinHTTP?
>
> Thank you.

Tnanks for response.  This answers a diffrent question.  I need to make 
WinHTTP to re-use already provided credentials and server's nonce from the 
previous [successful] request to generate Autorization header without a brand 
new login.


"David Wang" wrote:

> http://msdn2.microsoft.com/en-us/library/aa383144.aspx
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>

I guess I just do not understand what exactly is the problem. What
authentication protocol are you trying to re-use and what HTTP client
are you using?

If the previous successful request was made by WinHttp, then see
documentation on how to continue the authentication using that
protocol.

If the previous successful request was not made by WinHttp, then you
need to obtain the Authorization header from that request's API and
set it with WinHttp.

If you use custom authentication to obtain the credentials used to
generate Authorization for a given protocol, then you need to set the
right Authorization header yourself.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Mar 2, 7:12 pm, InsDivision_6
 wrote:
> Tnanks for response.  This answers a diffrent question.  I need to make
> WinHTTP to re-use already provided credentials and server's nonce from the
> previous [successful] request to generate Autorization header without a brand
> new login.
>
>
>
> "David Wang" wrote:
> >http://msdn2.microsoft.com/en-us/library/aa383144.aspx
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //- Hide quoted text -
>
> - Show quoted text -

1. First request WAS successfull using Digest authentication.

2. WinHttpQueryHeaders DOES NOT return any authentication headers sent with 
request nor recevied from the server.  It is kinda strange, but 
understandable (I mean I can accpet reasons why it works as it is, even I 
beleive it is an error).

3. The next request uses same hInternet and hConnect handles and tries to 
issue another HTTP request to the same server.  Server reply with 401, 
initiating authorization again, as for the first request.

4. I tried to use pre-authentication for the second request, but it does not 
work: WinHttpSetCredentials fails with "Invalid parameter" error - Digest is 
not allowed.
Since I do not have details on the Authentication negotiations, I cannot 
generate a proper Digest header.  Of course, I can ignore all WinHTTP 
authorization functions and do it on my own, but it doesn't make sense, since 
it has to be supported in a natural way.  Correct?


What I need is to make WinHTTP to continue to use the same Digest parameters 
sent by the server in the first attempt, without a new logon.  Same, as it 
would be in the Internet Explorer - typed credentials ones and do not get any 
passwords prompts.  The server programed in such a way that it behaves 
differently dependently on request:  if no valid Autorization provided, it 
starts from the beginning.  Therefore, I stick to the first [successful] 
request and cannot get out of the server the info I need.

"David Wang" wrote:

> I guess I just do not understand what exactly is the problem. What
> authentication protocol are you trying to re-use and what HTTP client
> are you using?
> 
> If the previous successful request was made by WinHttp, then see
> documentation on how to continue the authentication using that
> protocol.
> 
> If the previous successful request was not made by WinHttp, then you
> need to obtain the Authorization header from that request's API and
> set it with WinHttp.
> 
> If you use custom authentication to obtain the credentials used to
> generate Authorization for a given protocol, then you need to set the
> right Authorization header yourself.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> On Mar 2, 7:12 pm, InsDivision_6
>  wrote:
> > Tnanks for response.  This answers a diffrent question.  I need to make
> > WinHTTP to re-use already provided credentials and server's nonce from the
> > previous [successful] request to generate Autorization header without a brand
> > new login.
> >
> >
> >
> > "David Wang" wrote:
> > >http://msdn2.microsoft.com/en-us/library/aa383144.aspx
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //- Hide quoted text -
> >
> > - Show quoted text -
> 
>

I think we really need to sort out what is really going on to make any
progress because you are going down a dead-end.

I still do not see any problems. I just see a need for explanations.

#2 Unless your code directly performs the authentication protocol, it
is useless to give your code access to the authorization data
involved. Namely, secure authentication protocols render that data
useless to bystanders, as mitigation against replay and man-in-the-
middle attacks. You may choose to believe it is an error, but I just
see it as user misunderstanding of authentication protocols and
security.

#4 As documented, PreAuthentication does not work for Digest
authentication. If one reads the Digest RFC ( http://www.w3.org/Protocols/rfc2069/rfc2069
) as well as what PreAuthentication means, it is clear that you cannot
PreAuthenticate nor replay Authorization headers for Digest.

Why, you may ask? Well, since the Digest nonce is a server-generated
secret, the Client certainly cannot Pre-determine what the server will
generate, and if it can, that defeats the purpose of the nonce!

Personally, I think the problem is either with your understanding of
how the server operates, or the server's expectation of "user logon
session" which does not exist with HTTP, which combined with your
misunderstanding of how browsers and authentication protocol works,
leads you down the current dead-end.

Please re-evaluate how the server operates and how you are using it. I
suspect the incongruency is in there, but I know nothing about it, so
I cannot help further.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Mar 3, 3:06 pm, InsDivision_6
 wrote:
> 1. First request WAS successfull using Digest authentication.
>
> 2. WinHttpQueryHeaders DOES NOT return any authentication headers sent with
> request nor recevied from the server.  It is kinda strange, but
> understandable (I mean I can accpet reasons why it works as it is, even I
> beleive it is an error).
>
> 3. The next request uses same hInternet and hConnect handles and tries to
> issue another HTTP request to the same server.  Server reply with 401,
> initiating authorization again, as for the first request.
>
> 4. I tried to use pre-authentication for the second request, but it does not
> work: WinHttpSetCredentials fails with "Invalid parameter" error - Digest is
> not allowed.
> Since I do not have details on the Authentication negotiations, I cannot
> generate a proper Digest header.  Of course, I can ignore all WinHTTP
> authorization functions and do it on my own, but it doesn't make sense, since
> it has to be supported in a natural way.  Correct?
>
> What I need is to make WinHTTP to continue to use the same Digest parameters
> sent by the server in the first attempt, without a new logon.  Same, as it
> would be in the Internet Explorer - typed credentials ones and do not get any
> passwords prompts.  The server programed in such a way that it behaves
> differently dependently on request:  if no valid Autorization provided, it
> starts from the beginning.  Therefore, I stick to the first [successful]
> request and cannot get out of the server the info I need.
>
>
>
> "David Wang" wrote:
> > I guess I just do not understand what exactly is the problem. What
> > authentication protocol are you trying to re-use and what HTTP client
> > are you using?
>
> > If the previous successful request was made by WinHttp, then see
> > documentation on how to continue the authentication using that
> > protocol.
>
> > If the previous successful request was not made by WinHttp, then you
> > need to obtain the Authorization header from that request's API and
> > set it with WinHttp.
>
> > If you use custom authentication to obtain the credentials used to
> > generate Authorization for a given protocol, then you need to set the
> > right Authorization header yourself.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Mar 2, 7:12 pm, InsDivision_6
> >  wrote:
> > > Tnanks for response.  This answers a diffrent question.  I need to make
> > > WinHTTP to re-use already provided credentials and server's nonce from the
> > > previous [successful] request to generate Autorization header without a brand
> > > new login.
>
> > > "David Wang" wrote:
> > > >http://msdn2.microsoft.com/en-us/library/aa383144.aspx
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

#2.  Did not understand this statement.  I am translating it "if you are 
stupid, you do not need to know what we are sending on your behalf".  
Authetication headers were (and still?) available in WinInet, as far as I 
remember.

#3.  This is not [exactly] correct.  As soon, as server issues the "nonce" 
with 401 reply and client successfully answered with proper authorization 
header in the resending request, next requests(s) can reuse the same server 
nonce with a new client-generated nonce - "cnonce".  This is in RFC 2617.  
Therefore, new negotiations are not needed until server expires its nonce.  
This is what I call "pre-authentication", because it does not involves a new 
401 response (changes server's nonce) and a new authentication request.  I 
perfectly understand that Digest cannot be "pre-authenticated" until server's 
part of the "secret" is known, but I need "pre-authentication" WITHIN already 
authenticated "session".


"David Wang" wrote:

> I think we really need to sort out what is really going on to make any
> progress because you are going down a dead-end.
> 
> I still do not see any problems. I just see a need for explanations.
> 
> #2 Unless your code directly performs the authentication protocol, it
> is useless to give your code access to the authorization data
> involved. Namely, secure authentication protocols render that data
> useless to bystanders, as mitigation against replay and man-in-the-
> middle attacks. You may choose to believe it is an error, but I just
> see it as user misunderstanding of authentication protocols and
> security.
> 
> #4 As documented, PreAuthentication does not work for Digest
> authentication. If one reads the Digest RFC ( http://www.w3.org/Protocols/rfc2069/rfc2069
> ) as well as what PreAuthentication means, it is clear that you cannot
> PreAuthenticate nor replay Authorization headers for Digest.
> 
> Why, you may ask? Well, since the Digest nonce is a server-generated
> secret, the Client certainly cannot Pre-determine what the server will
> generate, and if it can, that defeats the purpose of the nonce!
> 
> Personally, I think the problem is either with your understanding of
> how the server operates, or the server's expectation of "user logon
> session" which does not exist with HTTP, which combined with your
> misunderstanding of how browsers and authentication protocol works,
> leads you down the current dead-end.
> 
> Please re-evaluate how the server operates and how you are using it. I
> suspect the incongruency is in there, but I know nothing about it, so
> I cannot help further.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> 
> 
> On Mar 3, 3:06 pm, InsDivision_6
>  wrote:
> > 1. First request WAS successfull using Digest authentication.
> >
> > 2. WinHttpQueryHeaders DOES NOT return any authentication headers sent with
> > request nor recevied from the server.  It is kinda strange, but
> > understandable (I mean I can accpet reasons why it works as it is, even I
> > beleive it is an error).
> >
> > 3. The next request uses same hInternet and hConnect handles and tries to
> > issue another HTTP request to the same server.  Server reply with 401,
> > initiating authorization again, as for the first request.
> >
> > 4. I tried to use pre-authentication for the second request, but it does not
> > work: WinHttpSetCredentials fails with "Invalid parameter" error - Digest is
> > not allowed.
> > Since I do not have details on the Authentication negotiations, I cannot
> > generate a proper Digest header.  Of course, I can ignore all WinHTTP
> > authorization functions and do it on my own, but it doesn't make sense, since
> > it has to be supported in a natural way.  Correct?
> >
> > What I need is to make WinHTTP to continue to use the same Digest parameters
> > sent by the server in the first attempt, without a new logon.  Same, as it
> > would be in the Internet Explorer - typed credentials ones and do not get any
> > passwords prompts.  The server programed in such a way that it behaves
> > differently dependently on request:  if no valid Autorization provided, it
> > starts from the beginning.  Therefore, I stick to the first [successful]
> > request and cannot get out of the server the info I need.
> >
> >
> >
> > "David Wang" wrote:
> > > I guess I just do not understand what exactly is the problem. What
> > > authentication protocol are you trying to re-use and what HTTP client
> > > are you using?
> >
> > > If the previous successful request was made by WinHttp, then see
> > > documentation on how to continue the authentication using that
> > > protocol.
> >
> > > If the previous successful request was not made by WinHttp, then you
> > > need to obtain the Authorization header from that request's API and
> > > set it with WinHttp.
> >
> > > If you use custom authentication to obtain the credentials used to
> > > generate Authorization for a given protocol, then you need to set the
> > > right Authorization header yourself.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > > On Mar 2, 7:12 pm, InsDivision_6
> > >  wrote:
> > > > Tnanks for response.  This answers a diffrent question.  I need to make
> > > > WinHTTP to re-use already provided credentials and server's nonce from the
> > > > previous [successful] request to generate Autorization header without a brand
> > > > new login.
> >
> > > > "David Wang" wrote:
> > > > >http://msdn2.microsoft.com/en-us/library/aa383144.aspx
> >
> > > > > //David
> > > > >http://w3-4u.blogspot.com
> > > > >http://blogs.msdn.com/David.Wang
> > > > > //- Hide quoted text -
> >
> > > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
> 
> 
>

#2. I translate the statement as "unless you are negotiating the
authentication handshake, knowing authentication headers is not
useful".

Unless APIs are created with similar goals, I do not bother comparing
them because they affect how the API operates. The best APIs are the
ones that expose the right level of information, not too much
complexity or too little control. The "right level" depends on the
goal of the API, not just merely "WinInet did it; why doesn't
WinHttp".

#4.
> I need "pre-authentication" WITHIN already
> authenticated "session

For Digest authentication, there is no such thing as "authentication
session". The reason is because Digest, like Basic Authentication, is
a per-request, evidence-based protocol. From the server's perspective,
there is no "user authentication session" that spans multiple requests
(unlike NTLM, which uses the TCP Connection as an authentication
session). Server only sees multiple authenticated requests from a
certain user.

Only way I can think of implementing Digest "user session" would be
for the server-side application to use some attribute of the
Authorization header, maybe in combination with the username and IP,
and attach security state to that. But, that totally depends on the
server-side application and is non-standard.

I really cannot help further without knowing what your server
application expects as a "user session" because it does not match your
description. And I note that what you currently want to do is an
impossible dead-end, so unfortunately, I cannot help with that.

Good luck.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Mar 3, 4:11 pm, InsDivision_6
 wrote:
> #2.  Did not understand this statement.  I am translating it "if you are
> stupid, you do not need to know what we are sending on your behalf".  
> Authetication headers were (and still?) available in WinInet, as far as I
> remember.
>
> #3.  This is not [exactly] correct.  As soon, as server issues the "nonce"
> with 401 reply and client successfully answered with proper authorization
> header in the resending request, next requests(s) can reuse the same server
> nonce with a new client-generated nonce - "cnonce".  This is in RFC 2617.  
> Therefore, new negotiations are not needed until server expires its nonce.  
> This is what I call "pre-authentication", because it does not involves a new
> 401 response (changes server's nonce) and a new authentication request.  I
> perfectly understand that Digest cannot be "pre-authenticated" until server's
> part of the "secret" is known, but I need "pre-authentication" WITHIN already
> authenticated "session".
>
>
>
> "David Wang" wrote:
> > I think we really need to sort out what is really going on to make any
> > progress because you are going down a dead-end.
>
> > I still do not see any problems. I just see a need for explanations.
>
> > #2 Unless your code directly performs the authentication protocol, it
> > is useless to give your code access to the authorization data
> > involved. Namely, secure authentication protocols render that data
> > useless to bystanders, as mitigation against replay and man-in-the-
> > middle attacks. You may choose to believe it is an error, but I just
> > see it as user misunderstanding of authentication protocols and
> > security.
>
> > #4 As documented, PreAuthentication does not work for Digest
> > authentication. If one reads the Digest RFC (http://www.w3.org/Protocols/rfc2069/rfc2069
> > ) as well as what PreAuthentication means, it is clear that you cannot
> > PreAuthenticate nor replay Authorization headers for Digest.
>
> > Why, you may ask? Well, since the Digest nonce is a server-generated
> > secret, the Client certainly cannot Pre-determine what the server will
> > generate, and if it can, that defeats the purpose of the nonce!
>
> > Personally, I think the problem is either with your understanding of
> > how the server operates, or the server's expectation of "user logon
> > session" which does not exist with HTTP, which combined with your
> > misunderstanding of how browsers and authentication protocol works,
> > leads you down the current dead-end.
>
> > Please re-evaluate how the server operates and how you are using it. I
> > suspect the incongruency is in there, but I know nothing about it, so
> > I cannot help further.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Mar 3, 3:06 pm, InsDivision_6
> >  wrote:
> > > 1. First request WAS successfull using Digest authentication.
>
> > > 2. WinHttpQueryHeaders DOES NOT return any authentication headers sent with
> > > request nor recevied from the server.  It is kinda strange, but
> > > understandable (I mean I can accpet reasons why it works as it is, even I
> > > beleive it is an error).
>
> > > 3. The next request uses same hInternet and hConnect handles and tries to
> > > issue another HTTP request to the same server.  Server reply with 401,
> > > initiating authorization again, as for the first request.
>
> > > 4. I tried to use pre-authentication for the second request, but it does not
> > > work: WinHttpSetCredentials fails with "Invalid parameter" error - Digest is
> > > not allowed.
> > > Since I do not have details on the Authentication negotiations, I cannot
> > > generate a proper Digest header.  Of course, I can ignore all WinHTTP
> > > authorization functions and do it on my own, but it doesn't make sense, since
> > > it has to be supported in a natural way.  Correct?
>
> > > What I need is to make WinHTTP to continue to use the same Digest parameters
> > > sent by the server in the first attempt, without a new logon.  Same, as it
> > > would be in the Internet Explorer - typed credentials ones and do not get any
> > > passwords prompts.  The server programed in such a way that it behaves
> > > differently dependently on request:  if no valid Autorization provided, it
> > > starts from the beginning.  Therefore, I stick to the first [successful]
> > > request and cannot get out of the server the info I need.
>
> > > "David Wang" wrote:
> > > > I guess I just do not understand what exactly is the problem. What
> > > > authentication protocol are you trying to re-use and what HTTP client
> > > > are you using?
>
> > > > If the previous successful request was made by WinHttp, then see
> > > > documentation on how to continue the authentication using that
> > > > protocol.
>
> > > > If the previous successful request was not made by WinHttp, then you
> > > > need to obtain the Authorization header from that request's API and
> > > > set it with WinHttp.
>
> > > > If you use custom authentication to obtain the credentials used to
> > > > generate Authorization for a given protocol, then you need to set the
> > > > right Authorization header yourself.
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
>
> > > > On Mar 2, 7:12 pm, InsDivision_6
> > > >  wrote:
> > > > > Tnanks for response.  This answers a diffrent question.  I need to make
> > > > > WinHTTP to re-use already provided credentials and server's nonce from the
> > > > > previous [successful] request to generate Autorization header without a brand
> > > > > new login.
>
> > > > > "David Wang" wrote:
> > > > > >http://msdn2.microsoft.com/en-us/library/aa383144.aspx
>
> > > > > > //David
> > > > > >http://w3-4u.blogspot.com
> > > > > >http://blogs.msdn.com/David.Wang
> > > > > > //- Hide quoted text -
>
> > > > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

> Only way I can think of implementing Digest "user session" would be
> for the server-side application to use some attribute of the
> Authorization header, maybe in combination with the username and IP,
> and attach security state to that. But, that totally depends on the
> server-side application and is non-standard.

You do not need "to think", because it is described in the standard and is 
based on "cnonce" and "nonce" combination. Server "nonce" defines the 
"session" and client's increasing "cnonce" value indicates sequential 
requests within this "session".
It is another question whether a particular server can or cannot support 
this.  But in our case we were talking about the client side.

Thank you for your efforts anyway, even the question remained not understood.

I submitted a paid question to Microsoft.  See, if money make any 
difference...