As most production environments we have setup something to send us a notification if there is an error in our web application. The problem is ofcourse that this only covers errors on the server side.
My question to the community is: What are you doing about client side errors, especially in javascript?
And what about other quality of service issues, such as slow processing and other things that might be due to the client machine?
You can handle client side JavaScript errors with window.onerror event
Inside the handler make an Ajax request to your server side error miner and log the error.
http://www.javascriptkit.com/javatutors/error.shtml
Hovewer window.onerror is not supported in all browsers, jQuery can fill up the gap with its own event handler: a combination of window.onerror and jQuery(window).error should suffice
There's not a great deal you can do about JavaScript errors at the client end. You can trap window.onerror and use it to AJAX a report back, but:
(a) it's not supported in WebKit or Opera. To catch all errors you would have to wrap every direct-execution, event and timeout entry point in a try { ... }, which is very messy and gives you even less information than the onerror handler.
(b) you will likely be swamped with error reports you can't do anything about, with little debugging possible due to lack of information. You might be able to get away with it on an application that is only accessed by customers you know, but on a public-access site, a lot of errors will be spurious. Stuff caused by factors like:
connections to sites hosting scripts or AJAX failing or being blocked by firewalls;
unexpected security settings (browsers have options to block many interfaces arbitrarily);
broken browser add-ons, GreaseMonkey-like scripts, filtering proxies and bogus “Internet Security” tools messing with your code;
unsupported agents that behave oddly, like mobile browsers (especially the appalling IEMobile) and, if they have access, automated-browser bots;
many errors caused by third-party content like adverts, if you have any.
Again, for a limited-use application where you can directly contact any user who is experiencing problems, it might be of use, but for a site used by the general public it's a non-starter.
It's best to use ‘progressive enhancement’ to ensure that your application still works when JavaScript fails.
Related
This is related to this security question regarding what it is that secures credentials inside a single page webapp.
Suppose we are using an app that is not ours and uses JWT Tokens for security. Are we able to log the contents through browser developer tooling or otherwise of the variables that the app uses for state. Specifically could someone log or see the contents of the JWT token that the user obtained post authentication?
Yes, it's entirely possible. Any user can just open the developer console and put breakpoints to see the value of the variables on runtime at a particular instance of time. This is how developers debug their applications.
The front end JS code runs on browser and since that needs to be interpreted, the source code needs to be downloaded on the browser and then run using a JS engine (V8 for chrome, webkit for Safari, Chakra for MS Edge etc.)
To secure your application you need to put as much business logic as possible on your server side code whenever security is concerned. With respect to JWT, I suggest you look at this SO question.
I'm currently using the "Developer mode" on the chrome://extensions page of the chromium browser, loading it by clicking on "Reload (Ctrl+R)".
I'd like to be able to make a change to my unpacked chrome extension and load it into the browser in an automated way, especially since I'm testing the extension on a virtual machine so doing all this completely headlessly would be ideal. However, I would at least like to avoid having to click every time I want to load my extension, and I'd like to be able to collect any errors produced into a file/tty.
What is the best way of doing this? Does chrome provide tools for automating extension building and testing?
Regarding the other question linked below:
It doesn't really address my problem, since I am looking for a way to get console output, stack traces and any output generated by the extension reload to be accessible via a file/stream in my OS, as opposed to being displayed in a chromium browser window. The linked answers provide a way to reload the extension programmatically, but not much else.
There are a few avenues for you to research.
You could look into enabling logging with a high verbosity. In principle, I would think there is a level that echoes console output; I'm no expert though.
You could use Native Messaging to speak to a daemon that will log things for you; the downside is that you probably can't catch errors this way.
You could take this one step further and create an extension that attaches to your target extension with Remote Debugging protocol (which provides the same info as DevTools) using the chrome.debugger API, and then log stuff with Native Messaging.
Or, you could eschew using an extension as a supervisor and just use/write an external Remote Debugging client.
At the moment I'm using Modernizr to detect if the client is blocking cookies and provide warnings if it's going to prevent them doing something i.e login or add to cart.
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/cookies.js
However I've found that if you use the Advanced privacy settings to block cookies this is not detected so the user doesn't get any warning and the site will appear to be broken.
I can't seem to find anything that suggests any way around this.
The Modernizr test is a purely client-side test. If IE's settings fool that test, it seems like you'll need to set a cookie in your main response, then do an ajax call and see if the cookie went back to the server. If it did, cookies aren't blocked; if it didn't, they are.
This also has the advantage that it's an end-to-end test: It doesn't matter where the cookie was blocked (the browser, a proxy, etc.), it'll tell you whether cookies currently work for that user in that environment with your site.
I've got this JS application. All client side JS communicating with a third party stream server via web sockets. I have about 18 different web sockets open for one page. Firefox and Chrome handle this many open web sockets at once just fine. IE11 seems to have a limitation of 4 open web sockets at once. Once I open that 5th web socket, regardless of socket call to the third-party server, I get an error thrown by IE, which closes the socket and gives the general error "SecurityError" and expanding the proto section it gives me . Seems to be pretty generic errors from my searches. At first I thought there may be a trusted zone type issue with IE, but I've added the client site to my trusted zone as well as the server providing the data.
This post provides info on max number of websockets for Firefox & Chrome, but I don't see anything specific about IE. Are there any known limitations to IE and web sockets? Answered, see edit below.
This MDN site talks about increasing the max value, but again, I can't find anything about IE. Is there some IE setting to up the amount of open connections? Answered: see below edit.
EDIT: This site shows the max connections settings for IE. It looks like it's a registry setting in Windows that controls the amount of web socket connections. Interestingly enough, I don't have that registry Key anywhere, but there is still a limit for this. The page speaks of IE10, and I'm working with IE11 specifically. Does anyone know if there are registry settings for this in regards to IE11? Has anyone just added these feature web socket registry keys and solved this issue?
The MSDN documentation you referenced is clear on the default being 6 concurrent connections (which means if not specified in the registry, that's what you'll get); and, if the documentation doesn't specify differently, it's probably safe to assume newer versions of Internet Explorer act in the same way as version 10.
Try setting through group policy. It worked for me.
https://jwebsocket.org/documentation/reference-guide/internet-explorer-tips
I'm using Facebook Connect in my app. I have it working pretty well, but in the Safari Error console, I'm seeing errors like this:
Unsafe JavaScript attempt to access frame with URL http://...#... from frame with URL http://www.connect.facebook.com/extern/login_status.phpapi_key=..&extern=2&channel=http...xd_receiver.htm.
Domains, protocols and ports must match.
The app seems to function ok, though we are seeing periodic hangs and other bad behavior from Safari. When I run other Facebook Connect apps, I sometimes see this error too, so I don't think this is a problem with our implementation. Is it safe to ignore this warning?
Safari's cross frame security is tighter than other browsers, I have done specific try/catch wrappers to handle these cases, if it otherwise works, great.
Either way, would post the bug upstream as olliej suggests.
It means you're attempting some form of cross origin access, which is unsafe -- while it may seem benign it's probably worth trying to find out why you're hitting it, if you use the nightlies or the Safari4 beta you can use the debugger in the web inspector, and make it break on all exceptions, which will let you see when it's actually attempting the cross-origin access.
As for the hangs, if you can find some kind of reduced testcase it would be great if you could file them at http://bugs.webkit.org
This is a red herring. The request still goes through and everything is working properly but WebKit still logs an exception.