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.
Related
I have a Comodo SSL certificate on my host plan, however when accesing my site from google, it sends me automatically to
http://example.com, Where the green lock doesn't appear.
If I manually add "https", like: https://example.com it does show up!
Is there a way to access my website always with the green lock showing up? instead of manually having to write it everytime?
You can easily redirect to the https version of any page using rewrite rules/rewrite module of your web server (the exact way to do this depends on the webserver used). Ask your provider, this is a common case so there may even be a UI option in your console to do this.
Regarding google see this: https://webmasters.stackexchange.com/questions/67212/how-to-convince-google-to-list-https-version-of-website
It may also be good form to verify the protocol used to access the site in your authentication module and refuse authentication if the wrong protocol is used. Assuming web rules are used to redirect traffic this would to prevent leaking information due to a misconfiguration/bug.
Recently I added SSL to my WordPress site but it started causing some problems (conflicts with Woocommerce and WP Super Cache plugins). The problem the I was having because of SSL was that the the Woocommerce cart was sometimes showing empty even after adding a product ans sometime the cart was not proceeding to checkout page. Do you think it had something to do with WP Super Cache or SSL or both? Anyway, I couldn't get it solved and removed the SSL after 2 days. But meanwhile Google had indexed the HTTPS URLs of my site and was showing them in the search results and they were returning SSL connection error. Now my question is how can I redirect all those HTTPS URLs to the HTTP ones? I asked my web host for help but said the redirection is not possible through htaccess or any other method. Was he right? How long will Google take to 'forget' these HTTPS links and show the HTTPS links again in search Results?
There are two standard ways to redirect:
At the DNS level
At the HTTP level
The DNS level can't help you because it just changes hostname. You want to keep the same hostname but change the scheme. This means you need an HTTP server to do the redirect.
In order to redirect from https to http you need to have an HTTPS service running on the computer with the IP address that the hostname resolves to.
Without that, there is nothing the receive the HTTP request over SSL and response with "Oh, this has moved to plain HTTP".
If the SSL service isn't running, then there is nothing that can do that.
(.htaccess is just a (suboptimal) means to configure an HTTP server, that does no good if you don't have the HTTP server listening on SSL).
Personally I'd fix the https issues. The world is going more https everyday so it's a backwards step to go from https to http. If you elaborate on what issues you had someone might be able to help.
However if you really want to do this then you need to run both http and https and redirect all traffic from https to http. How you do this depends on your set up (in Apache you'd do it using htaccess config).
How long it takes Google to fronded your site depends on many factors including the size and popularity of your site - which governs how often Google crawls your website. Give it a month at least for a small site. You can give it a kick by submitting your site to Google Search Console (the new name for Google Webmaster Tools).
Btw StackOverflow is primarily for programming questions so questions like this might be better asked on the http://webmasters.stackexchange.com sister site.
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.
I want to understand the technical background why it is not possible to track an HTTPS website with Piwik, when Piwik itself is installed on an HTTP server?
Somebody said, that if you would do that the browser would come up with an error message, but why?
I mean you do an HTTPS request, and on the bottom of the site is the tracking code to the HTTP Piwik site, that gets requested immediately. What's wrong about that?
All resources (such as the requests to Piwik) of the site requested through HTTPS have to go through the very same protocol since, otherwise, you will receive varying warning messages from different browsers (along the lines of "Your connection to XYZ is encrypted, however it contains resources that are not secure [...]").
So, to alleviate the problem, also Piwik has to be available via SSL.
The Piwik Javascript snipped already checks the protocol and redirects the user to the respective protocol. Now all you need to ensure is that your Piwik installation resides somewhere that has a valid SSL certificate.
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.