I'm using SignalR 2.0.3. I can't find working, reliable examples for this version of SignalR.
On the server, I have this:
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
var cfg = new HubConfiguration() { EnableJSONP = true };
cfg.EnableDetailedErrors = true;
map.RunSignalR(cfg);
});
On the client, I have this:
var settings = function() {
var connectionUrl = window.location.protocol + "//signalr.mydomain.com/signalr";
var queryString = "Email=JDentler%40dwhomes.com\u0026WindowsAccountName=jdentler";
return { connectionUrl: connectionUrl, queryString: queryString };
}();
$.connection.hub.url = settings.connectionUrl;
$.connection.hub.qs = settings.queryString;
$.connection.hub.logging = true;
$.connection.hub.start();
Here's my output from Chrome 35:
[20:27:50 GMT-0500 (Central Daylight Time)] SignalR: Auto detected cross domain url. jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:50 GMT-0500 (Central Daylight Time)] SignalR: Client subscribed to hub 'calendarhub'. jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:50 GMT-0500 (Central Daylight Time)] SignalR: Client subscribed to hub 'emailhub'. jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:50 GMT-0500 (Central Daylight Time)] SignalR: Client subscribed to hub 'notificationshub'. jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:50 GMT-0500 (Central Daylight Time)] SignalR: Negotiating with 'https://signalr.mydomain.com/signalr/negotiate?Email=JDe…ub%22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&clientProtocol=1.3'. jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:51 GMT-0500 (Central Daylight Time)] SignalR: Attempting to connect to SSE endpoint 'https://signalr.mydomain.com/signalr/connect?transport=s…2%3A%22emailhub%22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&tid=2'. jquery.signalR-2.0.3.min.js?_=1403573268960:8
EventSource cannot load https://signalr.mydomain.com/signalr/connect?transport=s…2%3A%22emailhub%22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&tid=2. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://webapp.mydomain.com' is therefore not allowed access. 764:1
[20:27:52 GMT-0500 (Central Daylight Time)] SignalR: EventSource calling close(). jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:52 GMT-0500 (Central Daylight Time)] SignalR: Opening long polling request to 'https://signalr.mydomain.com/signalr/connect?transport=l…2%3A%22emailhub%22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&tid=5'. jquery.signalR-2.0.3.min.js?_=1403573268960:8
XMLHttpRequest cannot load https://signalr.mydomain.com/signalr/connect?transport=l…22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&tid=5&_=1403573269504. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://webapp.mydomain.com' is therefore not allowed access. 764:1
// $.connection.hub.start().fail(...) called
[20:27:53 GMT-0500 (Central Daylight Time)] SignalR: Stopping connection. jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:53 GMT-0500 (Central Daylight Time)] SignalR: Fired ajax abort async = true. jquery.signalR-2.0.3.min.js?_=1403573268960:8
[20:27:53 GMT-0500 (Central Daylight Time)] SignalR: LongPolling failed to connect. jquery.signalR-2.0.3.min.js?_=1403573268960:8
Here's my output from Firefox 28:
"[20:46:01 GMT-0500 (Central Standard Time)] SignalR: Auto detected cross domain url." jquery.signalR-2.0.3.min.js:8
"[20:46:01 GMT-0500 (Central Standard Time)] SignalR: Client subscribed to hub 'calendarhub'." jquery.signalR-2.0.3.min.js:8
"[20:46:01 GMT-0500 (Central Standard Time)] SignalR: Client subscribed to hub 'emailhub'." jquery.signalR-2.0.3.min.js:8
"[20:46:01 GMT-0500 (Central Standard Time)] SignalR: Client subscribed to hub 'notificationshub'." jquery.signalR-2.0.3.min.js:8
"[20:46:01 GMT-0500 (Central Standard Time)] SignalR: Negotiating with 'https://signalr.mydomain.com/signalr/negotiate?Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22calendarhub%22%7D%2C%7B%22name%22%3A%22emailhub%22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&clientProtocol=1.3'." jquery.signalR-2.0.3.min.js:8
"[20:46:01 GMT-0500 (Central Standard Time)] SignalR: Attempting to connect to SSE endpoint 'https://signalr.mydomain.com/signalr/connect?transport=serverSentEvents&connectionToken=IrphkI69y7w99kTtN4TDaKWKKs%2FOrDOPVXdoVoXmXULtpLjfqihin%2BlCrux6H8oSFMHl6a2SMla7ex5nTJi8H1JwykxZoa82nu6Su1xfgcxTwwCfIC3K1R0aUenz5W3h&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22calendarhub%22%7D%2C%7B%22name%22%3A%22emailhub%22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&tid=1'." jquery.signalR-2.0.3.min.js:8
"[20:46:02 GMT-0500 (Central Standard Time)] SignalR: EventSource calling close()." jquery.signalR-2.0.3.min.js:8
"[20:46:03 GMT-0500 (Central Standard Time)] SignalR: Opening long polling request to 'https://signalr.mydomain.com/signalr/connect?transport=longPolling&connectionToken=IrphkI69y7w99kTtN4TDaKWKKs%2FOrDOPVXdoVoXmXULtpLjfqihin%2BlCrux6H8oSFMHl6a2SMla7ex5nTJi8H1JwykxZoa82nu6Su1xfgcxTwwCfIC3K1R0aUenz5W3h&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22calendarhub%22%7D%2C%7B%22name%22%3A%22emailhub%22%7D%2C%7B%22name%22%3A%22notificationshub%22%7D%5D&tid=3'." jquery.signalR-2.0.3.min.js:8
// $.connection.hub.start().fail(...) called
"[20:46:03 GMT-0500 (Central Standard Time)] SignalR: Stopping connection." jquery.signalR-2.0.3.min.js:8
"[20:46:03 GMT-0500 (Central Standard Time)] SignalR: Fired ajax abort async = true." jquery.signalR-2.0.3.min.js:8
"[20:46:03 GMT-0500 (Central Standard Time)] SignalR: LongPolling failed to connect."
Here's my output from IE 11, which works:
[20:51:08 GMT-0500 (Central Daylight Time)] SignalR: Auto detected cross domain url.
[20:51:08 GMT-0500 (Central Daylight Time)] SignalR: Client subscribed to hub 'emailhub'.
[20:51:08 GMT-0500 (Central Daylight Time)] SignalR: Negotiating with 'https://signalr.mydomain.com/signalr/negotiate?Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&clientProtocol=1.3'.
SEC7118: XMLHttpRequest for https://signalr.mydomain.com/signalr/negotiate?Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&clientProtocol=1.3&_=1403574667061 required Cross Origin Resource Sharing (CORS).
File: 764
[20:51:09 GMT-0500 (Central Daylight Time)] SignalR: This browser doesn't support SSE.
[20:51:10 GMT-0500 (Central Daylight Time)] SignalR: Opening long polling request to 'https://signalr.mydomain.com:443/signalr/connect?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&tid=0'.
SEC7118: XMLHttpRequest for https://signalr.mydomain.com/signalr/connect?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&tid=0&_=1403574667062 required Cross Origin Resource Sharing (CORS).
File: 764
[20:51:10 GMT-0500 (Central Daylight Time)] SignalR: Long poll complete.
[20:51:10 GMT-0500 (Central Daylight Time)] SignalR: Opening long polling request to 'https://signalr.mydomain.com:443/signalr/poll?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&groupsToken=7BwxejWvFqtNj3X0S%2FxPfHRzp3cpmj1x8Zo7XnRiXAOQoURl5UxKnMSyfxkxpFYeL6%2B2RLhX6jqPY8sRIJzrrhXr%2BTLC7Ygk3X28V3%2BJ8yJUjN082h0C15L7hEnutJW3RRXZUjC8QYfOjnoiQ%2BsZDI0D28SYXBVFSArZYiVLHhw%3D&messageId=d-B0017E39-h%2C0%7Cm%2C0%7Cn%2C1%7Co%2C0%7Cl%2C0&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&tid=1'.
SEC7118: XMLHttpRequest for https://signalr.mydomain.com/signalr/poll?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&groupsToken=7BwxejWvFqtNj3X0S%2FxPfHRzp3cpmj1x8Zo7XnRiXAOQoURl5UxKnMSyfxkxpFYeL6%2B2RLhX6jqPY8sRIJzrrhXr%2BTLC7Ygk3X28V3%2BJ8yJUjN082h0C15L7hEnutJW3RRXZUjC8QYfOjnoiQ%2BsZDI0D28SYXBVFSArZYiVLHhw%3D&messageId=d-B0017E39-h%2C0%7Cm%2C0%7Cn%2C1%7Co%2C0%7Cl%2C0&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&tid=1&_=1403574667063 required Cross Origin Resource Sharing (CORS).
File: 764
[20:51:11 GMT-0500 (Central Daylight Time)] SignalR: Long poll complete.
[20:51:11 GMT-0500 (Central Daylight Time)] SignalR: LongPolling connected.
Now connected, connection ID=8a624246-0e75-4dfc-99aa-8540da9e429d
[20:51:11 GMT-0500 (Central Daylight Time)] SignalR: Invoking emailhub.RefreshEmail
SEC7118: XMLHttpRequest for https://signalr.mydomain.com/signalr/send?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D required Cross Origin Resource Sharing (CORS).
File: 764
Notifications hub now connected, connection ID=8a624246-0e75-4dfc-99aa-8540da9e429d
Now connected, connection ID=8a624246-0e75-4dfc-99aa-8540da9e429d
[20:51:11 GMT-0500 (Central Daylight Time)] SignalR: Invoking calendarhub.RefreshCalendar
SEC7118: XMLHttpRequest for https://signalr.mydomain.com/signalr/send?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D required Cross Origin Resource Sharing (CORS).
File: 764
[20:51:11 GMT-0500 (Central Daylight Time)] SignalR: Opening long polling request to 'https://signalr.mydomain.com:443/signalr/poll?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&groupsToken=7BwxejWvFqtNj3X0S%2FxPfHRzp3cpmj1x8Zo7XnRiXAOQoURl5UxKnMSyfxkxpFYeL6%2B2RLhX6jqPY8sRIJzrrhXr%2BTLC7Ygk3X28V3%2BJ8yJUjN082h0C15L7hEnutJW3RRXZUjC8QYfOjnoiQ%2BsZDI0D28SYXBVFSArZYiVLHhw%3D&messageId=d-B0017E39-h%2C0%7Cm%2C0%7Cn%2C2%7Co%2C0%7Cl%2C0&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&tid=0'.
SEC7118: XMLHttpRequest for https://signalr.mydomain.com/signalr/poll?transport=longPolling&connectionToken=ORiixGPQGauG03eZCfeXkHT20wlPmnAgiZI%2Ft5R7CI1NKrrcaeNjbfVWFxrF7ogd7QwUjYu%2FPc9JlFCPiMcaiNVhHbI0CRlucj1egfEnXbDPK4c3WysNbaK%2FgHGorvOk&groupsToken=7BwxejWvFqtNj3X0S%2FxPfHRzp3cpmj1x8Zo7XnRiXAOQoURl5UxKnMSyfxkxpFYeL6%2B2RLhX6jqPY8sRIJzrrhXr%2BTLC7Ygk3X28V3%2BJ8yJUjN082h0C15L7hEnutJW3RRXZUjC8QYfOjnoiQ%2BsZDI0D28SYXBVFSArZYiVLHhw%3D&messageId=d-B0017E39-h%2C0%7Cm%2C0%7Cn%2C2%7Co%2C0%7Cl%2C0&Email=JDentler%40dwhomes.com&WindowsAccountName=jdentler&connectionData=%5B%7B%22name%22%3A%22emailhub%22%7D%5D&tid=0&_=1403574667064 required Cross Origin Resource Sharing (CORS).
File: 764
It turns out the request to connect was failing. This is because one of the hubs was replying to a new connection with data that blew up the JSON serializer. The resulting 500 response didn't have the CORS headers, so well-behaving browsers ignored the response. Fiddler is your friend. So is the Error Pipeline from the SignalR docs.
Related
I m using the primery key to connect to Cosmos via mobile app. When I set the time of the mobile device to automatic time everything works perfect, but when I set the time on the mobile device manually the token is not valid, because the country Jordan didn't change the time to winter time and kept sommer time,
I got this exception:
The authorization token is not valid at the current time. Please create another token and retry (token start time: Fri, 04 Nov 2022 11:19:39 GMT, token expiry time: Fri, 04 Nov 2022 11:34:39 GMT, current server time: Fri, 04 Nov 2022 10:20:39 GMT).
I think Microsoft Azure must also set the time for those countries correcrtly on its servers.
Any help?
I am getting below error while running Azure web job in scheduler -
Http Action - Response from host 'site.scm.azurewebsites.net': 'NotFound' Response Headers: Pragma: no-cache Cache-Control: no-cache Date: Wed, 28 Jun 2017 06:11:42 GMT Set-Cookie:
Path=/;HttpOnly;Domain=site.scm.azurewebsites.net Server: Microsoft-IIS/8.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Body: "No route registered for '/api/triggeredwebjobs/WebsiteEnquiries/run'"
please help me to resolve this.
According to exception, it seems that there is no named WebsiteEnquiries triggered webjobs. As David Ebbo mentioned that we could check the Webjob with kudu webapi(https://yourwebsite.scm.azurewebsites.net/api/triggeredwebjobs) to list the triggered Webjob.
We also could check the WebJob from the Azure portal.
I have a SharePoint provider hosted app deployed on Azure, with ASP.NET MVC. Because we chose to use AngularJS, we have added ASP.NET Web API controllers as well. We have managed to create the SharePoint client context in the API controllers by sharing the token information from the MVC controllers via cookies (the API controllers actions have a SharePointApiContextFilter just as the MVC controllers have the SharePointContextFilter to handle the SharePoint client context creation).
I have added an OData controller for reporting purposes, which will export data to Excel (via Excel's OData Data Feed import). I would like to make this controller to authenticate against SharePoint online. Excel has already implemented this functionality, since I have tried to import data from a SharePoint library via REST.
Using Fiddler, I have noticed the SharePoint online returns a 401 response with a authentication challenge (WWW-Authenticate) header:
WWW-Authenticate: IDCRL Type="BPOSIDCRL",
EndPoint="/sites/Test/_vti_bin/idcrl.svc/",
RootDomain="sharepoint.com", Policy="MBI"
This is the full response:
HTTP/1.1 401 Unauthorized Cache-Control: private, max-age=0
Content-Length: 0 Content-Type: application/xml;charset=utf-8 Expires:
Tue, 07 Jul 2015 07:34:08 GMT Last-Modified: Wed, 22 Jul 2015 07:34:08
GMT Server: Microsoft-IIS/8.5 X-SharePointHealthScore: 0
X-MSDAVEXT_Error: 917656;
Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.
DATASERVICEVERSION: 3.0 X-AspNet-Version: 4.0.30319 SPRequestGuid:
be6d1c9d-806b-2000-20ed-4d42443d8365 request-id:
be6d1c9d-806b-2000-20ed-4d42443d8365 X-FRAME-OPTIONS: SAMEORIGIN
X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 16.0.0.4121
X-Content-Type-Options: nosniff X-MS-InvokeApp: 1; RequireReadOnly
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo
OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI" WWW-Authenticate: IDCRL
Type="BPOSIDCRL", EndPoint="/sites/Test/_vti_bin/idcrl.svc/",
RootDomain="sharepoint.com", Policy="MBI" Date: Wed, 22 Jul 2015
07:34:08 GMT
Can somebody tell me how to construct this type of response in the OData controller (maybe via a custom action filter)?
Placing any content into blob storage within a container hosted on Microsoft Azure set to public blob appends various x-ms-... headers in the HTTP response to a standard GET request from a browser. What are they used for, and can they be turned off? I dislike bloated and useless HTTP headers.
HTTP/1.1 200 OK
Content-Length: 1841396
Content-Type: image/png
Last-Modified: Sat, 05 Jan 2013 22:27:08 GMT
ETag: 0x8CFB9AAEECBA7B9
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: dca0ba01-990b-439e-b9c9-11f698222d2e
x-ms-version: 2009-09-19
x-ms-meta-CbModifiedTime: Thu, 27 Dec 2012 18:23:17 GMT
x-ms-lease-status: unlocked
x-ms-blob-type: BlockBlob
Date: Sat, 05 Jan 2013 22:28:47 GMT
I faced the same problem recently and I want to share information.
First, "x-ms-..." headers except "x-ms-meta-CbModifiedTime" is set by Azure Blob.
I think Azure Blob, Azure CDN don't support the functions remove response headers now.
However, "x-ms-meta-{name}" headers return metadata set to each blob by not Microsoft but clients.
So who does create "CbModifiedTime" metadata?
I found CloudBerry Explorer ("Cb") set this metadata automatically.
I couldn't found the way to be disable this function in Free Edition.
If you care about response headers, you should consider to use other tools
Additional x-microsoft headers in the GET response can be removed using CDN endpoints Rules engine
We've successfully configured IIS to front 2 Tomcat instances using isapi_redirect.dll. It's doing everything smartly, and we've been very happy. Now, however, we're using one of the Tomcat instances to serve up web services through AXIS. This requires BASIC Auth, and .NET clients are failing.
+ .NET clients can bypass IIS by surfing to "site:8180" and they're fine
+ Java clients can hit IIS and ISAPI passes them through and they authenticate just fine using basic.
+ .NET clients that hit IIS fail to authenticate using the same unpw.
Fiddler reports this session:
HTTP/1.1 401 Unauthorized
Date: Wed, 07 Jan 2009 14:31:59 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
WWW-Authenticate: Basic realm="Daily Control Module"
Content-Type: text/html;charset=utf-8
Content-Length: 954
Proxy-Support: Session-Based-Authentication
It kicks up what looks like a basic auth dialog, but instead of asking us to auth against Daily Control Module, it asks us to auth against the Windows server. And sure enough, the IIS server is asking for an NTLM auth. If I set the entire server to use Basic Auth, I get this from Fiddler:
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="serverName"
X-Powered-By: ASP.NET
Date: Wed, 07 Jan 2009 15:08:32 GMT
Sigh. Basic, but now the Basic Realm is changed to the IIS server. So, if I set the entire server to authenticate against Basic realm, Daily Control Module, then I get this:
HTTP/1.1 401 Unauthorized
Date: Wed, 07 Jan 2009 15:11:45 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="Daily Control Module"
X-Powered-By: ASP.NET
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
WWW-Authenticate: Basic realm="Daily Control Module"
Content-Type: text/html;charset=utf-8
Content-Length: 954
Weird with the dual WWW-Auth headers, no? At any rate, authenticating using same unpw that works directly against Tomcat fails, whether I specify the domain or not.
At this time:
+ Anon is Off
+ Integrated Windows Auth is Off
+ Basic auth is On, with the realm configured as Daily Control Module
Thanks for looking.
What is the configuration of the directory security?
Are you sure that only basic authentication is enabled?
Other point is. Maybe in the iis level you should use anonymous authentication. And tomcat is taking care of implementing the basic authentication interchange?
The source of the problem ( from the header you posted ) is that the .net client recognize that the site support ntlm authentication. And try to authenticate with that protocol. The java client is just ignoring the ntlm option so it use whatever other authentication protocol the site supports.
You should make sure that the integrated authentication is not enabled in the site and file level.