I have some JS that is on some intranet application that's running on HTTP (this server/service is out of my control, run by the customer). I operate the internet application and it must run on HTTPS for security purposes.
I'm attempting to use XDomain but I'm finding that the cookies aren't being sent. Is the problem that I'm going intranet to internet or that I'm going HTTP to HTTPS or some configuration problem?
I keep getting 401 when checking authentication of the user even after they have logged in.
I've verified the backend/internet service works as expected via a jsfiddle (i.e. Access-Control-Allow-Origin, etc. are all correct).
Thanks!
There are some security related issues with XDomain that makes it strip any cookies according to no 5 in this msdn blog. However there also exist a workaround using proxy with example project on Github. I think everything you need to make it work are described in those two pages.
Related
I wanted to get help on this issue of mine.
Openshift is using https by default on its free applications,
whereas Heroku is using http
Whenever a visitor visits my website, he is presented with an Unsecure Connection warning.
How can we get rid of this warning or https altogether once and for all.
I am fine with http alone as
I am not willing to upgrade to silver for SSL thing only.
Nor do i have an SSL cert with me, am not planning on buying one.
Any thoughts?
strange thing I am also deploying my applications on openshift and they all are on http server. What ate the cartridges you are using??
OpenShift does not use https by default, we allow both http & https for free accounts and paid accounts. it may be something in your framework that you are using that is causing the redirect to https, it could also be that you visited the app before it was completely setup, and got redirected to https://app-domain.rhcloud.com/app, and now your browser is stuck on the https redirect. Try clearing your cache, test with another browser, or check the framework you are using to make sure it's not redirecting to https.
I am using Fiddler to inject a javascript library onto the page using:
oSession.utilDecodeResponse();
oSession.utilReplaceInResponse('</head>','<script src="//third_party_domain.com/js_file.js"></script></head>');
What would be the reason why this would not work on a certain secure (HTTPS) domain? It seems to work on every other domain I try this on (http and https).
I think it is related to Fiddler, as I know this has worked in the past - so perhaps it's a configuration setting I'm missing?
Fiddler can not read HTTPS pages unless it is configured to decrypt them. Check the checkboxes below on the HTTPS tab in Fiddler's options.
Details
I have an HTML5/JS website on on domain, which uses an asp.mvc web service for CORS queries on another domain.
Everything works fine with HTTP -> HTTP however as we are now adding login and authentication mechanisms for user specific content we are wanting to enable HTTPS. However it just refuses to send the options request to the web service, just gives an "Aborted" status.
I am testing using Firefox and the web service is hosted on IIS7 with a self cert (generated with SelfSSL7).
Is there any known issues around this? I did check:
Cross domain request from HTTP to HTTPS aborts immediately
However it mentions the solution is to make sure the cert is trusted, and to my knowledge SelfSSL is doing this using the /T option when I call it. So is there anything else which needs to be changed to get this working?
You will unfortunately need to manually set this in firefox, although I believe you can override this behaviour if you manually set the profile configuration.
I've been working on this Silverlight app for quite a while now. I have two dev machines. One has windows 7 and the other has windows 8. The SL app implements authentication through WCF and an implementation of MS membership engine. All was working well until I installed win8 on the other machine. Now, when I authenticate from this machine I get the cookie information back but any further request to the server is sent without the cookie information. It doesn't matter which browser I use and what my internet settings are (privacy/security levels all set to lowest... still same issue).
I looked at the requests on fiddler and compared between the two machines. They both send the same requests when logging in and the both receive similar data including the "Set-Cookie" header. The next request however, isn't similar. One machine sends this .ASPXAUTH cookie along with the ASP.NET_SessionId one and the other sends only the ASP.NET_SessionId. It's like it ignored the Set-Cookie command.
Any ideas how to solve this? I tried everything on my internet settings and nothing seems to make a difference.
Thanks,
Eyal
When I try to get data in a mobile flex app from a secure site, I get following alert:
A secure connection with this site cannot be verified. Would you still
like to proceed? The certificate you are viewing does not match the
name of the site you are trying to view.
For each call, I get the popup. If I keep on clicking Yes, the app works fine (but I would like to avoid that ;-)).
Any ideas? Apparently, the url from where the request comes, is not the same as defined in the certificate... But what is the url if called from a mobile app (standalone)? It's neither an error, because you can click on yes. So it's more that the client gives a warning. The annoying thing is that you can't accept it permanently...
This is the same whenever a cert is not correct and chrome or firefox alerts you and asks if you want to proceed. You cant accept a faulty cert on the behalf of your users. The easiest way to fix this is to tell the site owner to get a proper cert.
Check with your system administrators of website whether certificate installed is issued for your domain. It appears that certificate is issued for a domain https:///xxxx where as it is installed on https://yyyy
Bypassing is OK for testing , it seems finally you will have to get this corrected
In my experience this only comes up with self-signed certs, expired certs, and when you are calling the cert by a URL that is not identified in the cert.
With most certs they are associated with a single host/domain combination, i.e. https://www.domain.com
That means that they cannot be used with any other domain host combination. Not even http://domain.com or https://sub.domain.com.
There are certs that will support different hosts on the same domain (www.domain.com, sub.domain.com, etc). They are called wildcard cert. They are very expensive compared to normal single domain certs.
My guess is that in the browser you are calling www.domain.com but in your AIR app you are calling domain.com or calling some other host. That or you have permanently accepted the improper cert in the browser.
I have never have a problem with anything improperly identifying a valid cert. Not a browser, Flex app, AIR application. Ever.
If you view the cert in the browser you should be able to see what domain/host it is registered to. Make sure you are using exactly that. Any variation will cause the error.
As a temporarily solution I added some exceptions to the URL Rewrite Module, so that communication by Mobile App can be done with HTTP. But it's no longer secure, so I would rather use HTTPS.
I have also faces this issue and simple solution is fixed the certificate issue. If not possible then forget about using the HTTPS use HTTP only. So you never get any complain about any certificate issue.