I have a page where I am using swfobject and invoking the API's to control the youtube player.
When I run the application:
If the address is the local server (localhost) I can see all videos.
If I change the URL to my 192 internal address I get hit with the deadly restriction fail if these videos are marked as per the white and blacklists.
This seems like cheating but if I were to have a http server running on each client would this be illegal? If I could spin up an instance Cassini and now localhost solves the referrer issue.
Any thoughts?
Well, I run into the same problem and did some testing...
It seems, that Youtube restricts referers which consists of IP-Adresses.
For example, http://localhost/ works perfectly fine, no restrictions whatsoever, but with http://127.0.0.1/, bam, you're getting screwed.
Try putting
127.0.0.1 test.asd
into your hosts-file and surf to http://test.asd/. Should work fine.
So... what this means is, get yourself a domain (probably dyndns?) and everything should be fine.
Related
I'm developing with WebVR and I'm serving my HTML using the SimpleHTTPServer on my Mac. I want to figure out a way to access this website on my iPhone so I can see what I have created with my Google Cardboard.
I looked through a bunch of stack questions and none of them talked specifically about accessing a local website that is being served via SimpleHTTPServer
I tried getting my ip address and then concatenating the port
Ex. xxx.xx.xx.x : 8000
But it didn't work :( Also, both my phone and computer are on the same network too
Says This site can't be reached. IP_ADDRESS took not long to respond
The way I tried is the correct way. I was using school wifi so I'm assuming they're configured in a way that we aren't able to do that. Once I got home and tried on my local connection, it worked like a charm!
I have a Rails application hosted on Heroku and I am preparing to deploy another application that will use the same session cookie. Let's assume that main application is hosted at app.mycompany.com and the new application will be hosted at reports.mycompany.com. I've setup session cookies in both apps with cookie domain .mycompany.com and everything works ok. I've modified /etc/hosts to test those settings on my local machine.
Since everything worked fine on my local machine I wanted to test it on our staging environment, which is hosted at mycompany-staging.herokuapp.com. For this app I've set cookie domain to .herokuapp.com. And now it does not work. It is not possible to login. From inspector it looks like correct Set-Cookie header is sent from the server, but the browser never send this cookie back on request.
The same thing happens on my local machine when pointing mycompany-staging.herokuapp.com to 127.0.0.1. This happens only when I use herokuapp.com. Everything else works fine or at least couple of different domains work fine, including herokuapp2.com.
I am really confused. It looks like there is some cache issue, but I don't know where exactly. I am testing this mostly on Chrome with incognito mode, but I also tried Safari with the same problem.
Can anyone point me in the right direction? Or maybe I am missing something obvious.
This is because herokuapp.com is included in the Mozilla Foundation’s Public Suffix List. Cookie with domain *.herokuapp.com cannot be set any more. Refer to doc in devcenter.heroku.com:
herokuapp.com is included in the Mozilla Foundation’s Public Suffix List. This list is used in recent versions of several browsers, such as Firefox, Chrome and Opera, to limit how broadly a cookie may be scoped. In other words, in browsers that support the functionality, applications in the herokuapp.com domain are prevented from setting cookies for *.herokuapp.com. Note that *.herokuapp.com cookies can currently be set in Internet Explorer, but this behavior should not be relied upon and may change in the future.
When I test my ASP.Net app locally, I use a DNS tool called DNSSpeeder which takes over the DNS process for my machine. In effect, I can setup www.mysite.com locally and enter an IP address like 192.168.178.200 and in my browser just enter www.mysite.com and it launches from my local IIS web server. When I'm ready for production, I just disable DNSSpeeder so that an Internet's DNS is used to lookup my site.
The problem I am facing is when I use Google OAuth to exchange my code for a token. It returns with an error of redirect_uri_mismatch. It isn't clear to me what is actually going out on the wire to Google's server and what URI Google is seeing. The URI redirect does match what is in the API console, although that doesn't say anything about what is actually sent to Google's server after it leaves DNSSpeeder. I tried Wireshark but it shows nothing. Probably encrypted with https. Instead of using http://localhost:8080, I tried http://localhost:80 as well as http://192.168.178.200 for the Javascript origins but that didn't help.
Is it possible to use an IP address other than localhost when testing locally to get a successful token?
"Is it possible to use an IP address other than localhost when testing locally to get a successful token?"
Yes it is possible. My setup is that I have configured two redirect URLs in the Cloud Console, (http://www.mydomain.com/redirect and http://dev.mydomain.com/redirect).
I then edit /etc/hosts (on linux, the Windose equivalent is under system32\drivers somewhere) to map dev.mydomain.com to 127.0.0.1.
And it works just fine. You may need to tweak your app so the redirect URL is not hardcoded, but is in fact varied based on whether your app senses it's in dev or production.
One thing to be aware of is that the confiured redirect URL must be a character for character match to the actual URL. So be careful that you have both http and https variants, and also watch for a trailing slash. If necessary configure both with and without the trailing slash.
I'm setting up omniauth (just trying to get the facebook provider working for now).
I'm on my local computer running nginx on port 80. I route all requests to port 8080 and run the default webrick server on 8080.
I've set up omniauth pretty far, but now things only go smoothly in certain instances.
If my browser hits http://localhost/auth/facebook I get an error saying:
URI::InvalidURIError, the scheme http does not accept registry part: app_server (or bad hostname?)
If I hit however http://localhost:8080/auth/facebook, then facebook gives me an error message like Invalid redirect_uri: Given URL is not allowed by the Application configuration.". This makes sense since my site url is set to http://localhost not http://localhost:8080.
If I change the site url to http://localhost:8080, then things start to work (at least this far into the authorization process)
By the way, it's not just localhost by itself that is causing the problem. If I edit /etc/hosts and try something like dev.example.com it acts the same way, with dev.example.com not working and dev.example.com:8080 working.
Why can't I get it to work with just localhost? Is it something wrong with the way nginx and webrick talk to each other? I can't imagine that'd be the problem, but it's the only difference I see in what works and what doesn't. Any ideas why the URI error is occuring?
You need to edit the domain names for your facebook application. Go into https://developers.facebook.com/apps and edit the settings for that application. Set the site domain and app domains to whatever domain you want to allow redirection to (eg. example.dev)
I can't figure out what I'm overlooking, perhaps it's obvious or lack of understanding.
The app I'm working with uses subdomains which on the hosting server work properly. I figured locally installing would kick up some issues around routing, so I read up on making changes to /etc/hosts and using the Ghost gem. Both seem to work fine i.e. localhost:3000/ becomes myapp.local:3000 but I don't understand how to go about logging into a subdomain account. Here's an example...
myapp.local:3000/session/new = the default login page for the app
myapp.local:3000/signup = default signup page
I can create an account here e.g. Sub1
The thank you page is shown w/ the reference to sub1.myapp.com which points to the hosted app (the local db shows this domain as well)
sub1.myapp.local manually added to /etc/hosts and dscacheutil -flushcache
sub1.myapp.local:3000/session/new is the subdomain
login attempts return that this isn't a valid domain. This seems to make sense because the local db shows the url as sub1.myapp.com on the hosting server.
So my question is whether there's a local workaround that I can use for development or have I totally missed a fundamental concept along the way?
you might just want to try putting the actual dot com in your /etc/hosts file.
ie:
127.0.0.1 sub1.myapp.com
127.0.0.1 myapp.com
127.0.0.1 anyothersubdomains.myapp.com
what this usually does is trick your computer into thinking it is the host of all of those, so you can't go to the real site anymore in a web browser.
if you do want it to be .local, presumably so that you can refer to the real online site while working on a local copy, you should probably take a look in app/controllers/application_controller.rb (sometimes application.rb) and look for logic in there that helps determine what to do depending on the subdomain. maybe its hard coded to only look for a .com or something.
If you are using the webrick server or something like Puma for development you can use lvh.me to access your subdomains. e.g.
http://sub.lvh.me:3000/
http://lvh.me:3000/ is equal http://localhost:3000/