Server:
Ubuntu 14.04
Apache2
SSL enabled
Rails 3.2 Application
I have SSL implemented, using a self-generated certificate.
I have a REST API implemented as part of the Rails application (for a limited set of REST calls). I can call the API fine, using curl, and the http url end point.
When I try using the https end point, I get no response.
I tested https access to the application, from a web browser, and that's working fine, although the browser give me a warning, that the site is not safe.
Any ideas?
Related
i have an app running on Apple app store with webservices from HTTP Server but now i want to migrate my webservices from HTTP Server to newly brought HTTPS Server. What is the best approach to achieve this without affecting older application users running application on HTTP Server?
P.S: After migrating to new server, older server will not work.
Edit: my older server domain is going to expire and also i have amazon server on which i am going to move my webservices. So the older and new server link are different.
Thanks
I am using ASP .NET MVC 3 to develop a site running on IIS express server. The site has to run on https protocol.
I would like to add Twitter OAuth support to the site. Twitter requires a callback url and it should not be https://localhost:44300/. Normally, for http, I know the solution is to use http://127.0.0.1 instead. However, I have tried https://127.0.0.1:44300, it did not work for me and I got a HTTP 503 error.
Is there something I can do to get the callback working with https?
Follow these steps:
1- For IIS :
1-1 make sure that application pool is not paused or disabled
check here Solve HTTP Error 503
1-2 Make sure that SSL is enabled for IIS enabling SSL for IIS
2- Make sure that port 44300 is not used with anyother application, to check that run command:
"Netstat -a"
3- review Twitter Errors code
if everything is Okay on your machine,you might need to check twitter API errors code
For example error 503 means :
The Twitter servers are up, but overloaded with requests. Try again later.
Here is my cenario:
I have an Rails app on Heroku and i'm forcing it to use HTTPS (Using this tutorial: http://simonecarletti.com/blog/2011/05/configuring-rails-3-https-ssl/) .
I created a POST form, and its the action is "/my-action"
How do i know if my data is really been transmitted using SSL ? I mean, the form action shouldn't "https://mywebsite.herokuapp.com/my-action" ?
Some considerations:
* I'm using the free heroku SSL (https://myapp.herokuaapp.com )
* This app is not using the heroku SSL endpoint addon
Thanks
if you have valid ssl certificate and encryption key, then you only your data is accepted via ssl. Simply redirecting your website to use https protocol doesn't encrypt your data flow. And, this is what you were doing it. Right now, you are using heroku which does provide free SSL service if you use its domain.
So, if your website can be accessible via https://myapp.herokuapp.com and browser isn't giving any warning..then you are using SSL service.
This isn't applied if for custom domains. Your custom domain will still be accessible with https://www.example.com but it it SSL enabled.
Any way to test OAuth integration to google without having to have a port forwarding rule in my router back to my development Mac?
Background:
Developing Ruby on Rails web app that will request data from Google Calendar API via OAuth
Using Rails "OAuth Plugin" for this purpose
Developing on MacBook which is running my dev environment
Google needs (as part of OAuth) to make a callback back to my local dev environment
Can't seem to think of a way to test with Google without having to set a Port forwarding rule in my site's router back to my Macbook?
This threw me for a loop too. I actually went through the work of setting it up on a public IP even though I didn't have to in the end.
But yes, your comment is correct. The callback URL is passed on to Google during the redirect then after you've been authenticated with Google, Google will redirect you back to the callback URL providing an authorization code as a parameter.
The only server to server communication that happens is exchanging the authorization code for access and refresh tokens. This typically happens on the callback page. But since it's initiated by your server and not Google, no special open ports are required.
I've deployed my app on to a Ubuntu VPS using Capistrano, nginx/
Passenger and a wildcard SSL certificate.
The app works fine on development and my staging environment on
Heroku.
However, there are two problems on production when users sign into the
site using a secure page.
On latest Chrome and Firefox the browsers start to enforce HTTPS
requests on every single request every time. Regardless if the user is
signed in or not. Even if I disable SSL on nginx the browser still attempts HTTPS and complains it cannot connect. The main page serves some insecure dynamic embedded
items and uses an insecure CDN so I would like to serve that page as non-
SSL. Whenever I tried to redirect a page to non-SSL either through
nginx rewrite or a before filter in Rails it will cause an infinite
redirect loop.
Safari does not have the first problem as above it respects both
HTTPS and HTTP requests. However, when the user has logged in and
browses to a non-SSL page they are signed out or lose the session
instantly.
Has anyone encountered such a problem before or have an idea on how I could diagnose/fix the problem?
Thanks
Were you using Rails 3.1 force_ssl to enable SSL, or a gem?
When you enabled HTTPS, you also enabled the the HTTP Strict Transport Security flag, which the browse uses to immediately go to any HTTPS page on that domain before it sends the request to the server.
On Chrome, enter chrome://net-internals/#hsts into your browser and then you can delete your domain from the HSTS list which should fix it for Chrome. Can't speak for Firefox as I don't use it that often.
The issue with it losing session is likely because Rails is setting the authentication cookie as secure which means they are only sent for HTTPS requests and not HTTP. Make sure your cookie_options in Rails are not setting :secure => true. Also check the Devise cookie_options setting to ensure that :secure => true isn't being set.