My WCF service is throwing Unauthenticated & Unauthorised Fault Exception based on some validation. I want to handle these fault exceptions globally and then show them using a custom JS popup.
Is there any way to do this at global level.
Related
I have an Angular application that uses #angular/service-worker to register a service worker in the user's browser.
If the user has a certificate error in their browser (e.g. if the CN doesn't match), the service worker registration fails with the following error:
Service worker registration failed with: DOMException: Failed to register a ServiceWorker for scope ('[...]') with script ('[...]'): An SSL certificate error occurred when fetching the script.
This breaks some follow-up logic in my app, so it would be best if I could just not attempt service worker registration if I knew beforehand that this issue will occurr.
However, window.isSecureContext returns true, so I can't make the service worker registration depend on that.
Is there a way of detecting if the page is actually secure, and not just 'fake secure' with a red padlock in the URL bar?
In Firefox is there are no such issues, but in Chrome and Edge there seem to be different rules for window.isSecureContext and service worker registration.
I am aware that a proper SSL setup is the 'correct' solution, but in my situation, that unfortunately isn't possible.
I have a script loaded from a 3rd party domain (3p.com) into a webpage (page.com)
The goal is to capture error and unhandledrejection occurring in the 3p script and ping this back to a server for logging.
Whilst there are event handlers available in the browser for this, it seems they do not allow any meaningful collection of information, from the MDN site:
When an error occurs in a script, loaded from a different origin, the details of the error are not reported to prevent leaking information (see bug 363897).
Is there a way to do this? Ideal solution is global and hooks into these events, then allows filtering to only errors from the concerned script. However if would be happy to also wrap the script execution into a try / catch if this would capture all possible errors.
One option would be to set up your server so that requests to that third-party domain get bounced off your server, so that your clients have the ability to programatically examine possible errors that get thrown. For example, instead of serving to your clients
<script src="https://3p.com/script.js"></script>
serve
<script src="https://yoursite.com/get3pscript"></script>
where the get3pscript route on your site makes a request to https://3p.com/script.js, then sends the response to the client, making sure the MIME type is correct. Then the client will be able to do whatever it wants with the script element without cross-domain issues.
I use log4net in my ASP.NET MVC sites, and want to start using a similar package in my JavaScript (such as log4javascript) to do logging there. Especially logging of exceptions, but also debug logging if a user reports that something went wrong but it isn't readily reproducable.
I now have these questions about integrating log4javascript with ASP.NET MVC:
1) I want to send log messages to the server using log4javascript's AjaxAppender. Is there a package that will implement the web service that receives log messages and logs them server side?
2) I want to be able to set the level of client side loggers in the server side web.config, just as with log4net. This way I could switch on debug logging when needed without hacking JavaScript code (all JS will be combined and minified on production).
I guess on each page load the server can read the web.config and generate a bit of JavaScript that creates the client side loggers. Is there a package that does this?
log4javascript author here.
I don't know of a service that does this, but it's pretty trivial to do with a web handler and log4net.
Nothing I know of. I've considered writing an XML configurator for log4javascript but no-one's ever asked.
What is the best way to determine if a request being made to my REST service originated from a web client. I know I can look at the user-agent, but my concern is that is very easy to spoof.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
My site is built entirely in HTML and Javascript, any suggestions?
Or is there a good way in Javascript to store a hidden username / password I can use just for my website, without it being displayed to the public?
Thanks,
Adam
Anything put in the javascript can be found by using a debugger, such as Firebug, so even though it isn't visible to the user, it can be found by a user.
But, if the javascript first calls to a REST service to get an encrypted token, then the token, which has a timestamp encrypted within it, could be the password, so you then pass the username and token to call the rest of the REST services.
Your server could then validate that it had created the token and that it is not expired, and that the username matches what was encrypted in the token.
But, this depends on if you have any control over the REST service.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
This is not a good assumption. For the reasons you already gave (easily spoofed User-Agent), anyone could make a request to your application. You can even disable cross origin policy in firefox and chrome from the client side - so even if you could verify the request came from a browser, it's still possible to get around your security measures:
Disable same origin policy in Chrome
There are a couple of standard ways to implement security for this kind of service (as James mentioned, assuming you have control over the REST service).
Use Basic Authentication - If your application is communicating with the WCF service via HTTPS, basic authentication is probably the easiest method. See this question
If both your website and your WCF service are implemented using .NET, and your ASP.NET web application is using Forms Authentication, you could share the Forms Auth cookie and use that for authentication. See this question
I'm in need of a cross-platform solution for doing Digest Access Authentication correctly, and preferably using "qop=auth-int" for POST requests. It appears that only Opera will respond with qop=auth-int, and I.E. 6 has trouble w/ anything Digest.
So I thought to myself: I know, I'll just do an AJAX request and implement the authentication myself using setRequestHeader(). I've already implemented the server-side stuff necessary to do RFC-2617, so my only major hurdle here is figuring out how to gain sufficient control through javascript to get parse the 401 WWW-Authenticate header and form the appropriate response.
Here's the problem: It looks like the browser handles the 401 instead of allowing it to be passed along to XMLHttpRequest.onreadystatechange. If a user/pass is already stored for the site Chrome & Firefox will just silently handle tack on the Authentication header. If not, they will pop the normal login box.
Before you warn me of the inadequacies of Digest Auth & tell me I need to be using TLS--I realize the security risks. The server is a very resource-limited embedded platform, where SSL is not really an option. The server is not indented to appear on public internet. So the authentication is more to dissuade curious unauthorized people from making changes (think manager with good intentions but inadequate knowledge) rather than malicious attacker w/ the know how to do a MitM.