I get this error in my Ionic app when I run on my localhost with Chrome (ionic serve):
[Deprecation] getCurrentPosition() and watchPosition() no longer work on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS.
win # :8100/plugins/cordova-plugin-geolocation/www/android/geolocation.js:35
How to make it disappear ?
How to be sure there's no issue with a device ?
Try again using this plugin in your browser.
It allows to you request any site with ajax from any source, no matter http/https discrepancies and the like. Practically adds the Allow-Control-Allow-Origin: * header in the response.
Please keep in mind that this is a band-aid solution. Your server response has to actually have the 'Access-Control-Allow-Origin': '*' header, preferably with a more specific value than *.
Because switching to HTTPS can be painful or impossible depending on your architecture,
I found a workaround solution: you can use the Google Maps Geolocation API. Although it has usage limits, it does the job. You will need an browser API key, so don't forget to limit it's usage to your page hostname.
I use it as a fallback method to the getCurrentPosition() method if it fails. It allows me to make it work until I switch to HTTPS.
Here's the JSFiddles:
HTTP: getCurrentPosition() will fail and fall back to the API
HTTPS: getCurrentPosition() will succeed
Related
I keep receiving the error below when I use Ionic Serve...
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access.
It only occurs with "post" request. The "get" requests I have work with no error. I've seen documentation for proxy's but I was not looking to go that route. I'm currently using the CORS Chrome plugin as a workaround right now, but will be shipping to mobile soon (Ionic view) for testing, which I believe I will still run into the CORS issue using Ionic View.
I have control of the API/server - using nginx.
Any suggestions?
Cors will not affect to mobile phone. The issue is in POST method in web view. In Post methods Browser send OPTIONS Request for security Purpose. It should handle in API. I used ASP.NET WEB API When Using localhost I Used Two Methods for post in Same Name but it's not proper way for doing this. You need to handle in Configuration to Igonre this. If you have API without parameters add headers "content-type x-www-form-urlencoded" to you request header. If there are parameters. use another method without parameters using same name.(Method overloadin). But when you are using livehost don't forget to remove redundant methods.
The title pretty much says it all. I know I can bypass it in my browser with --disable-web-security (for chrome) but how does it work for releasing the app? I have no access to the server that is set to deny reverse proxies and only accepts GET requests not OPTIONS this leads to prefight issues. How can I work around this?
I've taken a look at these but they don't seem to answer the prefight from release workaround. Any Suggestions/workarounds?
http://blog.ionic.io/handling-cors-issues-in-ionic/
https://blog.nraboy.com/2014/08/bypass-cors-errors-testing-apis-locally/
Download Chrome cors extension
Do not call a post call from the service, do that from a controller
At the server side make sure you have a option route for every route you have available
Perform a post request like this
$http->post('you api', your_data)
.success(function(response) { ..}).error(function (error) {..})
.finally(function() {..});
Also get palanik/lumencors if your server runs with laravel
You need not worry about CORS in a ionic app build, as in the recent ionic projects, the cordova plugin cordova-whitelist will already be put as part of the config.xml, so when you make a build, it handles the CORS issue by itself.
My restler 3 api works fine on local test server and works fine on production server if calls from that same server, but if I make the call remotely then it fails.
Using the same rest client with the luracast online examples it works fine with remote call so must be something in my configuration (either my api or my production server).
I found mention of need to send headers and so tried adding these headers to index.php file:
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, PATCH, DELETE');
header('Access-Control-Max-Age: 1000');
header('Access-Control-Allow-Headers: *');
But that didn't help. Using RESTClient addon in firefox, I can see that those headers are sent, and the browser will show the data both locally and remotely, whether I use those header commands or not.
Here's a sample call:
https://api.masterpiecesolutions.org/v1/artists/?key=A4oxMOYEUSF9lwyeFuleug==
My index.php for that call uses this, with 2nd param to map to root level
$r->addAPIClass('Artists', '');
Don't know if that is relevant.
Also, the production server is Amazon EC2, so perhaps has something to do with security policy?
Or, maybe it's some other header issue? In google chrome, using Advanced Rest Client extension, it gives status of 403 Forbidden and Content-Type is text/plain (whether using local or remote server) so it won't work at all, unlike the firefox addon.
I also see use of $_SERVER['HTTP_ORIGIN'] in Restler.php, and this doesn't appear to be supported everywhere yet?
* is not a valid value for the Access-Control-Allow-Headers response header. You need to list out every non-simple request header. For example:
header('Access-Control-Allow-Headers: Content-Type');
Also consider putting a single origin value or just * for the Access-Control-Allow-Origin header. I just visited your sample url and there are multiple values in that header. Although this should work according to the CORS spec, it is not very widely adopted yet.
Lastly I noticed that the server was setting Access-Control-Allow-Credentials: true. If you set this to true, then you also need to do two other things:
The value of the Access-Control-Allow-Origin header must be the value of the Origin (e.g. http://localhost, it can not be *).
You will need to set xhr.withCredentials = true; in your JavaScript client code.
If you are just testing, you should try to get things working without setting the Access-Control-Allow-Credentials header. It will make things easier to debug.
The problem, for me at least, was using SSL and the restclient class didn't accommodate that.
So I added (to my RestClient.class.php from phpclasses.org)
curl_setopt($this->curl, CURLOPT_SSL_VERIFYPEER, false); // for SSL
and now it works.
Also required was setting
public static $crossOriginResourceSharing = true;
in Defaults.php for Restler 3.
I am using Sinatra and CORS to accept a file upload on domain A (hefty.burger.com). Domain B (fizzbuzz.com) has a form that uploads a file to a route on A.
I have an options route and a post route, both named '/uploader'.
options '/uploader' do
headers 'Access-Control-Allow-Origin' => 'http://fizz.buzz.com',
'Access-Control-Allow-Methods' => 'POST'
200
end
post '/uploader' do
...
content_type :json
[{:mary => 'little lamb'}].to_json
end
The options gets hit first... and it works.. then the post gets hit and returns a 403.
If I disable protection, the post works... what kind of protection do I need to exclude from a list to maintain protection but allow these posts through?
I have only recently been burned by the new Rack protection kicking in on Heroku and causing me some grief... anyone have a good pointer for what to do here? The reason I say that, is all of a sudden I am seeing log entries with alerts to session hijacking issues (almost certainly due to nothing more than running > 1 Dyno for the App). I see rack-protection (1.2.0) in my Gemfile.lock even though I never asked for it... something in my manifest is calling for it, so it is loaded, but nothing in my Sinatra App even tries to require it or set it up.
Using this in your Sinatra app should solve your problem:
set :protection, :except => [:json_csrf]
A better solution may be to upgrade Sinatra to 1.4, which uses Rack::Protection 1.5 and should not cause the problem you are seeing.
The problem is that your version of RackProtection::JsonCsrf in is incompatible with CORS when you respond with Content-Type: application/json. Here is a snippet from the old json_csrf.rb in rack-protection:
def call(env)
status, headers, body = app.call(env)
if headers['Content-Type'].to_s.split(';', 2).first =~ /^\s*application\/json\s*$/
if referrer(env) != Request.new(env).host
result = react(env)
warn env, "attack prevented by #{self.class}"
end
end
result or [status, headers, body]
end
You can see this rejects requests that have an application/json response when the referrer is not from the same host as the server.
This problem was solved in a later version of rack-protection, which now considers whether the request is an XMLHttpRequest:
def has_vector?(request, headers)
return false if request.xhr?
return false unless headers['Content-Type'].to_s.split(';', 2).first =~ /^\s*application\/json\s*$/
origin(request.env).nil? and referrer(request.env) != request.host
end
If you are using Sinatra 1.3.2 and cannot upgrade the solution is to disable this particular protection. With CORS you are explicitly enabling cross-domain XHR requests. Sinatra lets you disable protection entirely, or disable specific components of Rack::Protection (see "Configuring Attack Protection" in the Sinatra docs).
Rack::Protection provides 12 middleware components that help defeat common attacks:
Rack::Protection::AuthenticityToken
Rack::Protection::EscapedParams
Rack::Protection::FormToken
Rack::Protection::FrameOptions
Rack::Protection::HttpOrigin
Rack::Protection::IPSpoofing
Rack::Protection::JsonCsrf
Rack::Protection::PathTraversal
Rack::Protection::RemoteReferrer
Rack::Protection::RemoteToken
Rack::Protection::SessionHijacking
Rack::Protection::XssHeader
At time of writing, all but four of these are loaded automatically when you use the Rack::Protection middleware (Rack::Protection::AuthenticityToken, Rack::Protection::FormToken, Rack::Protection::RemoteReferrer, and Rack::Protection::EscapedParams must be added explicitly).
Sinatra uses Rack::Protection's default settings with one exception: it only adds SessionHijacking and RemoteToken if you enable sessions.
And, finally, if you are trying to use CORS with Sinatra, you might try rack-cors, which takes care of a lot of the details for you.
If you see this issue, you are not using CORS (Cross-origin resource sharing), and are behind a reverse-proxy (such as nginx or apache), make sure that your reverse-proxy isn't stripping out host header and replacing it with localhost.
For example, in nginx you need to use proxy_set_header:
location / {
proxy_pass http://localhost:9296;
proxy_set_header Host $host;
}
When the header is stripped out from a request, Rack::Protection believes it to be a CSRF attack.
Let me guess, you're testing with the Chrome app 'Dev HTTP Client' ? Try this instead:
curl -v -X POST http://fizz.buzz.com/uploader
From the rack protection module:
"Supported browsers:: Google Chrome 2, Safari 4 and later"
This should work:
class App < Sinatra::Base
...
enable :protection
use Rack::Protection, except: :http_origin
use Rack::Protection::HttpOrigin, origin_whitelist: ["chrome-extension://aejoelaoggembcahagimdiliamlcdmfm", "http://fizz.buzz.com"]
post '/uploader' do
headers \
'Allow' => 'POST',
'Access-Control-Allow-Origin' => 'http://fizz.buzz.com'
body "it work's !"
end
You probably wonder about chrome-extension://aejoelaoggembcahagimdiliamlcdmfm ? Well, that's what the rack protection gets as env['HTTP_ORIGIN'] when you send a POST request with the Chrome app.
Is this because you are not returning the allowed methods back in your options route?
A question here refers to it which notes the allowed methods back.
An extension here and middleware here might help you out.
rack-protection allows to specify a custom check starting from 2.0.0:
set :protection, :allow_if => lambda{ |env| env['HTTP_REFERER'] && URI(env['HTTP_REFERER']).host == 'fizz.buzz.com' }
https://github.com/sinatra/sinatra/blob/a2fe3e698b19ac4065f166f1727afd31d0e72f95/rack-protection/lib/rack/protection/json_csrf.rb#L39
Why does using Fiddler break my site sometimes on page transitions.
After a server side redirect -- in the http response (as found in Fiddler) I get this:
Object moved
Object moved to here.
The site is an ASP.NET 1.1 / VB.NET 1.1 [sic] site.
Why doesnt Fiddler just go there for me? i dont get it.
I'm fine with this issue when developing but I'm worried that other proxy servers might cause this issue for 'real customers'. Im not even clear exactly what is going on.
That's actually what Response.Redirect does. It sends a 302 - Object moved response to the user-agent. The user-agent then automatically goes to the URL specified in the 302 response. If you need a real server-side redirect without round-tripping to the client, try Server.Transfer.
If you merely constructed the request using the request builder, you're not going to see Fiddler automatically follow the returned redirect.
In contrast, if you are using IE or another browser, it will generally check the redirect header and follow it.
For IE specifically, I believe there's a timing corner case where the browser will fail to follow the redirect in obscure situations. You can often fix this by clicking Tools / Fiddler Options, and enabling both the "Server" and "Client" socket reuse settings.
Thanks user15310, it works with Server.Transfer
Server.Transfer("newpage.aspx", true);
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Read more here:
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm