I'm setting up an iOS app to use the IP Messaging and video calling apis. I'm able to connect, create channels and setup a video call if I manually create hard-coded tokens for the app. However, if I want to use the PHP server (as described here https://www.twilio.com/docs/api/ip-messaging/guides/quickstart-ios) then I always get an error and it can't connect anymore.
I'm attaching a screenshot of what I see when I hit the http://localhost:8080 address which seems to produce a 500 Internal error on this URL: https://cds.twilio.com/v2/Streams
Thanks so much!
After much time spent on this I decided to try the node backend instead - under other server-side languages of the PHP and I have it running in 2 minutes! I used the exact same credentials as the ones that I was using on the PHP config file so either my PHP environment has something strange or the PHP backend needs some fixing. In any case, I'm able to move forward using the node backend, so if you run into the same issue just try node instead of PHP. woohoo!
Related
I am working on a web app where a single environmental variable is used for specifying a certain server (a rest api), like this:
.env:
...
URL_SERVER_API="http://localhost:8080"
...
the application is running inside a container, and it uses the server api variable for two things related to my problem:
It could generate and serve dynamic html where it append URL_SERVER_API to complete full api urls, for example {{URL_SERVER_API}}/someendpoint
It calls the api directly from a (php) script using CURL, defining the endpoint in the same fashion as 1
so I end up with a situation where if I set URL_SERVER_API to localhost:8080 the main application forms valid urls to call because the api app (which is also running in a docker container) was exposed in the correspondingly port, but the CURL calls don't work because localhost:8080 is not a known server inside the container.
Also I configured a bridge network and attached both apps to it, and I was capable to ping from the main app to the api succesfuly (e.g. ping api_docker), then when I set URL_SERVER_API=api_docker the CURL calls to the api are successfull, but the html files returned from the main app are constructed with unreachable urls like http://api_docker/someendpoint
Hope you can see my issue
I am able to solve the issue by having two variables URL_SERVER_API and URL_SERVER_API_INTERNAL and using the first for html serving and the second for the CURL calls, but I think it is not the best solution to add new variables to remember because I am not in charge to do so.
Thanks for the time taken to read
App engine requests have location-aware headers (X-AppEngine-Country, X-AppEngine-Region, X-AppEngine-City) automatically added. Does Cloud Run have something similar?
This is (will be) possible with Google Cloud HTTP(S) Load Balancer via user-defined headers.
However, putting your Cloud Run service behind the load balancer is currently in alpha, so you cannot try this out today. You can wait for a while, or if you’re willing try the alpha out and give feedback, please contact me. #ahmetbtodo
AFAIK, these Google custom header values doesn't exist today. However, in the current headers you can find the IP of the originated requester (here in IPv6)
forwarded: for="2a01:cb14:af0:b500:ccf6:1a91:1713:b48";proto=https
x-forwarded-for: 2a01:cb14:af0:b500:ccf6:1a91:1713:b48*emphasized text*
You can use external services to know the exact location.
I'm currently developing a Wolkenkit application which is run on my local machine.
I want to upload a file from the Wolkenkit app to the blob server (as documented here).
When sending a POST request from the server to https://local.wolkenkit.io:3001/, Node.js gives me the error ECONNREFUSED.
I've tested the POST-Request with another program and it works there. Any idea why it doesn't work from the wolkenkit application itself?
Thanks!
The Storing files sample you linked to shows code that is to be run in the browser, not in the backend itself. Of course, both should work, but there are a few minor differences you need to watch out for.
Fixing the host name
First, I suppose that local.wolkenkit.io in your case maps to 127.0.0.1, which is the default for wolkenkit. That means that when you try to connect to this domain from within a Docker container, the container does not try to call out to the blog storage container, but it stays within itself. So, the first thing that needs to be fixed is the host name.
Basically, there are two options for this: You can either setup local.wolkenkit.io so that it resolves to the external IP address of your machine. This would work, but is pretty cumbersome. The other option is to directly address the appropriate container that is responsible for blob storage, by its internal name. The internal name is <name-of-your-app>-depot-file. So you need to replace https://local.wolkenkit.io:3001/ by https://<...>-depot-file.wolkenkit.io:3001/.
Fixing the port
Second, the port is wrong. This is because the blob storage service is internally running on port 3000, externally on 3001. So instead of https://<...>-depot-file.wolkenkit.io:3001/ you need to use https://<...>-depot-file.wolkenkit.io:3000/.
Once you have done this you should not get any more errors like ECONNREFUSED, since now the service can be found.
Fixing SSL issues
Third, since you are now connecting to the blob storage service using a different domain name, the SSL certificate doesn't match any more, since it was issued for local.wolkenkit.io. As a result, you will get SSL errors when trying to connect.
The simplest way to get around this is to disable any SSL checks (albeit this is also the most insecure way to handle this!). How to do this depends on the HTTP client module you are using. E.g., in request there is an option called strictSSL that you can set to false.
Of course, what you actually should do is to either use a custom certificate which includes this domain name as well, or to write a function that handles the certificate check and accepts the presented one, especially in this case.
If you do all of this, things should work :-)
PS: I am one of the authors of wolkenkit. Thanks a lot for bringing up this issue, and we will take care of this in the future, to make storing blobs easier.
I have a Node JS Server where I am using Socket.IO to stream content to the browser. It works great for about 45 minutes or so of streaming, then it will usually cut out. There are no "errors" reported in the terminal and the Node server acts like it is in, however the page I am serving clearly stops working.
What are my options for trying to get to the bottom of this? Could this be a configuration issue with Node/Socket.IO? is there any basic error logging you would recommend I setup?
Hard to say without seeing your code, but Socket.IO for NodeJS requires a heartbeat to maintain connection. It could be a bug in the client code for sending the heartbeat.
I'm working on an app that uses Yahoo OAuth. The OAuth had been working fine but I just registered my domain with Yahoo and now it will not let me use the OAuth when I develop locally because
"Custom port is not allowed or the host is not registered with this consumer key."
The issue is because my call back URL is to a domain that is not registered with Yahoo (http://localhost:8080/welcome).
I'm not sure what to do. I'm also new to development so if you could be specific with suggestions that would be awesome! Any help is greatly appreciated.
Hiii... yahoo works on localhost :).. what you have to do is while registering for a yahoo consumer key and secret key, the registration page asks you what type of application is yours. I guess it gives you two options , website and the oder one as stand alone app. Choose stand alone app as in your case. Then it will give you a pair of keys, and it will work on localhost :). Enjoy!
It looks like Yahoo! doesn't want you to do this. Some answers from similar questions might be helpful (or not):
How do I develop against OAuth locally?
401 Unauthorized using Yahoo OAuth
Yahoo OAuth question
EDIT: more evidence Yahoo! doesn't support this: http://developer.yahoo.net/forum/?showtopic=6496&cookiecheckonly=1
I found the simplest solution was just to register for a separate key for my development environment. As long as you don't verify the domain for that key, you shouldn't hit any issues.
After many attempts, I too came to the conclusion that Yahoo's redirect_uri does not seem to work with ports other than 80.
The one solution that worked for me:
Download ngrok
Run the app and input ngrok http xxxx in the console - where xxxx is the port you are trying to access
The command will generate a http://xxxxxx.ngrok.io forwarding link that can be used for Yahoo's needs
Create a new Installed Application at https://developer.yahoo.com/apps/create/ and input http://xxxxxx.ngrok.io in the Callback Domain field.
Links should now work with this redirect_uri
Addressing Muhammad's comment in Vignes's answer here because I can't comment. You should be able to use a callback with a stand alone app if you specify 127.0.0.1 as the callback domain. You may also needed to change the port that your local server is listening to, because you cannot request that yahoo use e.g. port 8000. Make sure your local server is listening to port 80.
As of writing, setting the Application Type to Installed Application and then leaving the Callback Domain blank will give you errors.
What works is configuring 127.0.0.1 as the Callback Domain for the app. This works regardless if you are choosing Web Application or Installed Application as the Application Type. However, Yahoo! does not accept callback URLs with ports in it so you have to make sure your app listens to port 80 (or 443 if https) when running locally.
Another less ideal option would be using some random non-existent domain like local.dev.env.com as Callback Domain and then editing your hosts file by adding this:
127.0.0.1 local.dev.env.com
This will forward all requests on local.dev.env.com to 127.0.0.1.