working on chat application using SignalR.
onDisconnected() is called after some time but not immediately in the chrome browser when the user closes or logged out.
But in the Firefox browser, it does get called immediately.
After using
this code in JS
window.onbeforeunload = function (e) {
$.connection.hub.stop();
};
now it is working in the Chrome browser
but then onDisconnected() is called very late when the user get logged out from the Firefox browser
please help
Can't find any worked so it works in all browser
Thank you
Related
This is iOS specific issue.
I have completed all the steps suggested in document over here https://azure.microsoft.com/en-in/resources/samples/active-directory-b2c-xamarin-native/
In Andtoid it is working fine. But in iOS it is not returning back to application after successful login.
Yes, Login page is displaying properly we can enter the credentials over there but once login in successful then browser is closed but debugger not attaching back to application.
I have Eneabled Keychain access, Added Url Types in info.plist and also added below code to AppDelegate.cs
public override bool OpenUrl(UIApplication app, NSUrl url, NSDictionary options)
{
AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs(url);
return true;
}
And on FInishLaunching event I have added below code
var authenticationService = DependencyService.Get();
// Default system browser
authenticationService.SetParent(null);
Actually I am calling SignInAsync method from OnAppearing event of view. So after successful validation OnAppearing event is firing again and it lost the previous flow.
Please let me know if I am missing something. Your help is much appreciated.
Thanks.
I am using SignalR (with cross-domain request), version 2.3.0 for webchat integrated to ASP.NET site. Everything is working fine. But I found strange behaviour of SignalR connection. When I clicked to the reference from tab of the chat for file downloading SignalR connection was aborted and onDisconnected method was triggered in my Hub class. FireBug show me next POST-request:
http://*:81/signalr/abort?transport=longPolling&clientProtocol=1.4&token=eUpLNitKcmR1d2JhTTRvcHNVZmEwcG1EKzYvMElZbmg4aE5yam9xM3k0dz0_IjAsNGJmOWNhODUtNDU2NS00NWExLWFjMTgtNzgyN2FhZDA2Njg1LGxvY2FsaG9zdCI1&State=1&connectionToken=hDXe9xIZtmrapjl1LRwtK9B%2BfYMoeuHka8ctBLaPa0YnjiN9iiFa%2BvFMBHIGpGH0h8qPEDgGZSRGwjMw3Wm1DJi6cUPtZjLca6%2FR2576SGksLAj3lnPN1JWIlxMsn8%2Bf&connectionData=%5B%7B%22name%22%3A%22c%22%7D%2C%7B%22name%22%3A%22voip%22%7D%5D, where * is my domain.
It is reproduced in Mozilla Firefox (version 30.0) for LongPolling or Websocket transports. How I can fix this problem? Or is it bug of SignalR or Firefox?
This bug has been recently filed against SignalR on GitHub. The basic idea is that downloading a file causes Firefox to trigger the window.onbeforeunload event which in turn causes SignalR to close any ongoing connections.
For now, the workaround is to attach a handler to the client's disconnected event that will call $.connection.start again after a short window.setTimeout.
You could also unbind SignalR's onbeforeunload handler: $(window).unbind("beforeunload"). The downside of doing this is that Firefox might not gracefully disconnect when the user leaves the page running SignalR. Without a graceful disconnect, SignalR will wait over 30 seconds before it times out the client and calls the OnDisconnected handler on the Hub or PersistentConnection.
I have managed to use the workaraound explained by halter73 and I have solved the issue described by dudeNumber4 resetting the connectionid inside the disconnect event so that the server kept calling back the right users based on their connectionid without the need to address them by their user or group names.
$.connection.hub.disconnected(function () {
setTimeout(function () {
$.connection.hub.start().done(function () {
$("#mySignalRConnectionIdHidden").val($.connection.hub.id);
});
}, 3000);
});
When navigating away from a page that has signalR connection/connected hub I get the following error message.
The connection to "http://localhost:53604/signalr/signalr/connect?transport=serverSentEvents&connectionId=0b308c0d-2122-4e60-a9fa-f6e3f3eb1f4e&connectionData=%5B%7B%22name%22%3A%22packageactionstatus%20%22%7D%5D&tid=9" was interrupted while the page was loading.
I do understand that the connection was lost (which is Ok) due to navigating away from the page but is there a safe way to stop the connection before navigating away from the current page?
You can close the connection onunload:
$.connection.hub.stop();
Though I'm not sure why do you care of this error.
To do this properly you want to trap the onbeforeunload event, and you want to do it like so:
window.onbeforeunload = function () {
$.connection.hub.stop();
};
Fixed the problem for me with firefox.
In my webapp, I have a list of links generated from code-behind and bound to a repeater control. Clicking on a link opens a popup window, where, along with displaying some data, an asynchronous call to a WCF Service is made (through a javascript proxy). This service in turn calls another third party web service that might take a long time to respond. I am working with IE6, thats a unavoidable requirement.
Now, I abort this service on onunload if the user decides to not wait for the call to complete and just closes the popup window. The problem is, if the user clicks another link from the repeater immediately after, the new popup window opens but doesn't load the page (doesn't go to the supplied URL) till the previous asynchronous call has completed (I have verified this through Fiddler). Interestingly, this only happens for links within the same domain. If I change the link for one of the popus to, say, www.google.com, then the window opens and goes to the correct url as intended. But, for popups with links within my own domain, which are opened immediately after a popup window with an unfinished request was closed, it waits till the previous request completes before loading the url.
I have verified the correct way to abort a callback and abort does fire properly. I also know that I can only abort my client side call, and not the server side call and I don't care about it. My only requirement is that the browser load the next link regardless of the previous asynchronous response.
//Method to Call Service:
function GetData(Id) {
//call the service
Sys.Net.WebRequestManager.add_invokingRequest(On_InvokingRequest);
var service = new WrapperService();
service.GetData(Id, handleSuccess, handleError, null);
Sys.Net.WebRequestManager.remove_invokingRequest(On_InvokingRequest);
}
//method to get the current requests abort executor
function On_InvokingRequest(executor, eventArgs) {
var currentRequest = eventArgs.get_webRequest();
abortExecutor = currentRequest.get_executor();
}
//abort service on unload
function unload() {
if (abortExecutor != null) {
abortExecutor.abort();
}
}
Helpful/Similar links for the background:
browser-waits-for-ajax-call-to-complete-even-after-abort-has-been-called-jquery
aborting-an-asp-net-web-service-asynchronous-call
canceling-ajax-web-service-call
Anybody faced this before? Its driving me nuts! Any help will be greatly appreciated.
The answer in one of your links sounds like the problem to me:
Browser waits for ajax call to complete even after abort has been called (jQuery)
Does your service require session state?
You could prove whether the problem is that IE itself won't issue the request by configuring IE to allow for more than 2 requests to the same domain. If it's being blocked because the aborted request is somehow eating up one of those connections, then increasing it should yield different results. If it still has the problem, it must be that the server is waiting to respond.
Configure IE for more than 2 requests:
http://support.microsoft.com/kb/282402
Quote from one of the SO questions you linked:
It turns out I was completely wrong about this being a browser issue - the problem was on the server. ASP.NET serializes requests of the same session that require session state, so in this case, the next page didn't begin processing on the server until those ajax-initiated requests completed.
Unfortunately, in this case, session state is required in the http handler that responded to the ajax calls. But read-only access is good enough, so by marking the handler with IReadOnlySessionState instead of IRequiresSessionState, session locks are not held and the problem is fixed.
I have a few internal .net web application here that require users to "log out" of them. I know this may seem moot on an Intranet application, but nonetheless it is there.
We are using Windows authentication for our Intranet apps, so we tie in to our Active Directory with Basic Authentication and the credentials get stored in the browser cache, as opposed to a cookie when using .net forms authentication.
In IE6+ you can leverage a special JavaScript function they created by doing the following:
document.execCommand("ClearAuthenticationCache", "false")
However, for the other browsers that are to be supported (namely Firefox at the moment, but I strive for multi-browser support), I simply display message to the user that they need to close their browser to log out of the application, which effectively flushes the application cache.
Does anybody know of some commands/hacks/etc. that I can use in other browsers to flush the authentication cache?
I've come up with a fix that seems fairly consistent but is hacky and I'm still not happy with it.
It does work though :-)
1) Redirect them to a Logoff page
2) On that page fire a script to ajax load another page with dummy credentials (sample in jQuery):
$j.ajax({
url: '<%:Url.Action("LogOff401", new { id = random })%>',
type: 'POST',
username: '<%:random%>',
password: '<%:random%>',
success: function () { alert('logged off'); }
});
3) That should always return 401 the first time (to force the new credentials to be passed) and then only accept the dummy credentials (sample in MVC):
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult LogOff401(string id)
{
// if we've been passed HTTP authorisation
string httpAuth = this.Request.Headers["Authorization"];
if (!string.IsNullOrEmpty(httpAuth) &&
httpAuth.StartsWith("basic", StringComparison.OrdinalIgnoreCase))
{
// build the string we expect - don't allow regular users to pass
byte[] enc = Encoding.UTF8.GetBytes(id + ':' + id);
string expected = "basic " + Convert.ToBase64String(enc);
if (string.Equals(httpAuth, expected, StringComparison.OrdinalIgnoreCase))
{
return Content("You are logged out.");
}
}
// return a request for an HTTP basic auth token, this will cause XmlHttp to pass the new header
this.Response.StatusCode = 401;
this.Response.StatusDescription = "Unauthorized";
this.Response.AppendHeader("WWW-Authenticate", "basic realm=\"My Realm\"");
return Content("Force AJAX component to sent header");
}
4) Now the random string credentials have been accepted and cached by the browser instead. When they visit another page it will try to use them, fail, and then prompt for the right ones.
A couple of notes. A few people have said that you need to fire off a ajax request with invalid credentials to get the browser to drop it's own credentials.
This is true but as Keith pointed out, it is essential that the server page claims to accept these credentials for this method to work consistently.
On a similar note: It is NOT good enough for your page to just bring up the login dialog via a 401 error. If the user cancels out of the dialog then their cached credentials are also unaffected.
Also if you can please poke MOZILLA at https://bugzilla.mozilla.org/show_bug.cgi?id=287957 to add a proper fix for FireFox. A webkit bug was logged at https://bugs.webkit.org/show_bug.cgi?id=44823. IE implements a poor but functional solution with the method:
document.execCommand("ClearAuthenticationCache", "false");
It is unfortunate that we need to go to these lengths just to log out a user.
Mozilla implemented the crypto object, available via the DOM window object, which has the logout function (Firefox 1.5 upward) to clear the SSL session state at the browser level so that "the next private operation on any token will require the user password again" (see this).
The crypto object seems to be an implementation of the Web Crypto API, and according to this document, the DOMCrypt API will add even more functions.
As stated above Microsoft IE (6 upward) has:
document.execCommand("ClearAuthenticationCache", "false")
I have found no way of clearing the SLL cache in Chrome (see this and this bug reports).
In case the browser does not offer any API to do this, I think the better we can do is to instruct the user to close the browser.
Here's what I do:
var agt=navigator.userAgent.toLowerCase();
if (agt.indexOf("msie") !== -1) {
document.execCommand("ClearAuthenticationCache","false");
}
//window.crypto is defined in Chrome, but it has no logout function
else if (window.crypto && typeof window.crypto.logout === "function"){
window.crypto.logout();
}
else{
window.location = "/page/to/instruct/the/user/to/close/the/browser";
}
I've been searching for a similar solution and came across a patch for Trac (an issue management system) that does this.
I've looked through the code (and I'm tired, so I'm not explaining everything); basically you need to do an AJAX call with guaranteed invalid credentials to your login page. The browser will get a 401 and know it needs to ask you for the right credentials next time you go there. You use AJAX instead of a redirect so that you can specify incorrect credentials and the browser doesn't popup a dialog.
On the patch (http://trac-hacks.org/wiki/TrueHttpLogoutPatch) page they use very rudimentary AJAX; something better like jQuery or Prototype, etc. is probably better, although this gets the job done.
Why not use FormsAuth, but against ActiveDirectory instead as per the info in this thread. It's just as (in)secure as Basic Auth, but logging out is simply a matter of blanking a cookie (or rather, calling FormsAuthentication.SignOut)
Well, I've been browsing around Bugzilla for a bit now and seemingly the best way you can go for clearing the authentication would be to send non-existant credentials.
Read more here: https://bugzilla.mozilla.org/show_bug.cgi?id=287957
Hopefully this will be useful until someone actually comes along with an explicit answer - this issue was discussed two years ago on a message board.
HTH