Is there a way to determine if a browser supports NTLM without having NTLM enabled for the particular site or directory in IIS and without showing a login dialog/pop-up? Preferably, determine this using ColdFusion or perhaps some combination of JS and CF. I'd prefer not to restrict this to just IE as other browsers (such as FF) support NTLM authentication.
If you request a page and the page returns 401 and says it only accepts NTLM, and then the browser sends another HTTP packet trying to respond to it, then it supports NTLM. You don't have to make IIS do this -- you could have any page where you can set the response codes and headers request NTLM. If you don't get another request, it means that the client couldn't authenticate this way.
You could detect this on the client by putting this request in an IFrame, then in the outer page checking to see what happened in the iframe.
Building on Lou's answer, you could make a cfhttp request within a try/catch block. You then check the response headers to determine your next steps.
Unfortunately, you may be forced to use browser sniffing and a white-list.
Related
I recently found (here: Does every web request send the browser cookies?) that every HTTP request contains the cookies related to a domain every time a request is made to that same domain.
Given this, what happens when the request is not sent through a browser but from Node.js, for example? Is it possible that no information is sent in the request?
Is it also possible to prevent it to be sent in the browser requests?
Browsers
Is not possible to prevent browser to send cookies.
This is why is generally it is recommended (Yahoo developer Best practice, see section Use Cookie-free Domains for Components) to serve static content like css, images, from a different domain that is cookie free.
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
Programmatically
From any programming language, instead, you can choose if you like to send cookies or not.
Cookie management is done by the programmer, because libraries are written to make single requests.
So if you make a first request that return cookies, you need to explicit read them, hold them locally somewhere, and eventually put them in a second request to the same server if you need.
So from NodeJS if you don't explicitly add cookies in your requests the http call doesn't hold them.
You Can Use Fetch with the credentials option set to omit
see
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
You can strip cookies with a proxy server. For example our product WinGate will allow you to modify requests (and responses), and you could use this to clear the Cookie header in requests.
However, this will prevent a large number of websites from functioning properly, as cookies are used to transport session IDs so that the server can identify each connection / request your browser makes as being from the same "session". HTTP itself does not have any concept of session.
Disclaimer: I work for Qbik who make WinGate.
I use jquery and jQuery.ajax.
And I want to connect SSL page with ajax from noSSL page.
Is there any browsers which connects server without SSL when connects server with SSL fails using ajax?
I mean if this code fails,
$.post('https://xxxxxx')
browser connect "http://xxxxxx" automatically.
Is there any browser which behave this?
I want to know security risk of jQuery.ajax .
Of course I think the behave is nonsense. But I want to get the evidence to know all browser don't behave this. So, What shold I read? I read the WC3 XMLHttpResponse. But All browser apply this specification?
If you specified https in your ajax call url, there is no reason the browser will try http(as it's not asked to). It would be, as you say, a security risk.
Imagin if you are on your bank website and for some reson their https fail. It would be a nonsense to try it with http
We're developing a Dynamics CRM 2011 product that has a button in the ribbon that calls an external API. Currently, for this button to work, the following settings need to be changed in the browser (IE):
We would like to avoid this, because many of the target customers for this product are very security conscious. Is there a way to write the code so that it will not require these permissions to be changed, but still be able to communicate with the external API? The code running when the button is pressed in CRM is HTML and Javascript.
Thanks!
Are you in control of the API? If so, look into CORS. With CORS, all you do is basically add a few extra headers to your request response. If you use an AJAX library (like jQuerys $.ajax), you should be able to continue writing code as is. If not, a good article on how to implement cors in Javascript can be found here: http://eriwen.com/javascript/how-to-cors/
To enable cors, read up on http://enable-cors.org/
I don't know anything about this CRM, but other than JSONP, your best bet is to have a server side script act as a proxy.
So, you would create a script within the same domain as the user interface code. That script will then use a server side language (such as PHP) to perform the request to the cross domain script on your behalf. The server side connection has no restriction on which domain it can access, and all the browser knows is that it is sending a request to a page within the calling domain, which is presumably safe.
How you will do this depends on the exact language of choice, but in general you would just need to send the remote API URL as well as any arguments needed to your server side script, which then rebuilds the request to that URL and passes the result back to the client.
I currently have a RESTful webservice which recognises a client via it's session.
I have a client which uses ajax/javascript to access the contents of the RESTful webservice. I allow this to happen by responding to the request with the headers: Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods.
However, although the client can access the content's each request is regarded as a different session as cookies cannot be used across domain.
I don't want to modify my server code to cater specifically for this style of client, i would prefer a work around client side to give a facade of using a session.
Since I don't want to store anything through the session, rather I only use the jsessionid as the client identifier I assumed I could artifically inject &jsessionid= to the URL to, at least from the server side, make the client seem to be correctly keeping track of the session.
This doesn't seem to work - can someone advise on how I can make my client act as if it is using the same sessionid?
...I assumed I could artifically inject &jsessionid= to the URL...
jsessionid isn't a query string parameter. You'd want to artificially add ;jsessionid=... (prior to any & in the URL), rather than &jsessionid=....
For background...I made a product called kitgui.com which allows for cross domain communication and simulates on-page saving for content management but actually is talking cross domain through an iframe to a secure server.
You don't have to modify your server code. You can use iframe + postMessage assuming you don't need support for below IE8. All the other modern browsers support that. There is also iframe polling technique as well for lower browsers. You don't need to expose your session id across querystring on non SSL either. You can talk to your iframe to get the state of being logged in or not via javascript. The session info remains on the iframe's domain where it should be.
This link can help you -> http://benalman.com/projects/jquery-postmessage-plugin/
I run a site A and I want to be able to POST data to site B, which is hosted on a different subdomain. Now I have complete access to A, but cannot modify B at all.
My requirements are:
supports file upload
does not refresh browser on POST
uses Windows integrated security
works in IE 7/8 (does not need to support any other browsers)
What's the best way to accomplish this?
What I've tried:
Ideally this could be done in a simple AJAX call. However the current standard does not support sending binary data (supported in the XMLHttpRequest Level 2 standard, which is not implemented in IE yet).
So the next best thing is to POST to a hidden <iframe> element. Now I've tried this but the server on site B won't accept the data. I looked at the request and the only discrepancies that I found were the referer URL and the integrated authentication. The referer URL might have to be spoofed, which cannot be accomplished by this method. Also for some reason the authentication isn't being negotiated. I'm not 100% sure why.
Ideas:
I'm thinking of creating a proxy page on the server that I run (site A) that forwards the request to site B. Site A also uses integrated security. I don't see anything wrong with this, but I'm not sure if this is the best way to go. Will there be any authentication issues if I just forward the request over?
Using a proxy seems to be the only thing which can work in your case. If you want to make a get request then it can be done using JSONP provided that the server supports JSONP. To make the <iframe> hack work the server should send the headers as
Access-Control-Allow-Origin:*
which is not the case with you.
So using a proxy seems the solution