I have an API in a .NET project that I'm running with Visual Studio Mac (8.4.3). I run it in release mode, and it opens a browser window with localhost:5000. The browser window says "ok". However, when I try to hit endpoints in that API, it fails very quickly. When I ran this API (ie. same code) from another server and accessed it via proxy, it ran fine. For example, when I ran it on a server whose IP was 162.250.198.98 and proxied into it, I would hit an endpoint like 162.250.198.98:3000/api/user and it would work, but now when I try to run localhost:5000/api/user, either from my app or from Postman, it fails almost instantaneously. When running it in Postman, I tried what it suggested by turning off 'SSL certificate verification' in Settings, but no change.
Can anyone advise me on how to approach troubleshooting this?
Wait, so You are saying that while trying to call API on 162.250.198.98:3000/api/user You are fine but while trying to do the same thing on localhost:5000/api/user You are getting an error? Would it might be possible You have Your API configured to receive calls at 3000? :)?
No, but really - please chech it out, maybe it is that simple, I'm couting on it :).
You can change/check it in Visual Studio: main project > Properties > Debug > App URL.
Related
TCP connections work fine as I am able to converse with someone over zoom and teamviewer. However, whenever I attempt to access another webpage, I get a network error. Google seems to work fine for some reason but any webpage I go to listed by Google fails to connect. The only way I can open up my http connections is by ending a task called "init" inside of task manager. This shuts down my vscode as well as my ubuntu terminals I have running. If someone knows the solution please do tell. It's really annoying having to close out my vscode and terminals as well as my local servers to look up information and debug.
I found a fix to this issue.
So I was running a Windows Subsystem for Linux and my Windows Build was outdated as well as WSL. When I updated Windows and upgraded to WSL2, my issue was resolved and I don't seem to get any more network errors.
I'm trying to add a Google Sign In Authentication system to my app, but I keep getting a strange error that I haven't seen anyone get. I'm using EXACTLY the google example code.
I thought it could be some mistake when loading the api, so I checked the async loading and everything seems to be loading properly, but I keep getting this error in the console:
gapi.auth2.ExternallyVisibleError: Invalid cookiePolicy
I searched everywhere for people with the same problem, but I could not find anything similar.
Any ideas?
EDIT: I tried to create a page with ONLY the code of the tutorial, but the error still occurs.
Well, turns out I was trying to test the API by directly acessing my files locally (index.html). The Google Sign In API only works in a running web server. I started a simple node.js server, ran my app trhough this server, and everthing worked just fine.
As already answered by KoJoVe, you need to run inside a web server. If you are using Python 2.7 you might use python -m SimpleHTTPServer 8000 and then use localhost:8000 on your browser
I've been trying to get a chrome extension to work for a very long time, and I recently decided to click into the error. The reason is because the google platform script checks window.location.protocol (which isn't https for chrome extension) and throws the error 'invalid cookie policy'.
My theory as to why Google won't fix this:
They want to drive people into using paid OAuth2 endpoints
They want to know who received the tokens, if possible (via certificate authorities)
I was having this problem using react-google-login in a create-react-app, and I found that I was accessing the page with http://[::1]:3000/sign_in instead of localhost.
I think google does not like 127.0.0.1 or ::1 since we expose the IP directly or something
When I change to localhost:3000 and it worked.
This worked in my case with python 3:
open python terminal and write the following code:
from http.server import SimpleHTTPRequestHandler as handler
import socketserver as socket
httpd = socket.TCPServer(("",8000),handler)
httpd.serve_forever()
Recently I added email sending capability to my Meteor app, using both the email package, and the account registration APIs to send emails. The other day, after having tested this thoroughly on my dev machine, I deployed it to our production server using Meteor Up. Once deployed, I did a quick check that the email APIs were working properly, and let it be. A day or two later, I made some minor changes, wrapping these email APIs in a Meteor.defer method to speed up the UI. I tested the changes locally (all fine), and re-deployed. I also ran apt-get update on my server after seeing a notification there were some new security updates available. After doing this, the email system no longer works. I tried reverting back to my previous configuration, and it still isn't working. I'm getting a timeout error:
Exception while invoking method 'forgotPassword' Error: connect ETIMEDOUT
I was wondering if anyone had any ideas on what might be causing this timeout (a blocked port?...how can I diagnose this?). Given my SMTP port is working on my development machine, it doesn't seem to be an issue with my code, but rather either with the MUP deployment, or Ubuntu configuration. I'm not super familiar with configuring Ubuntu servers. Any suggestions on how to go about de-bugging would be greatly appreciated!
We got a similar problem, and it was solved by opening the needed port in EC2. thanks to https://kylegoslin.wordpress.com/2012/06/05/116/
On localhost, the app works just fine.
On EC2, the app runs behind nginx. It loads into the browser, but nothing shows up. The browser console displays an Error
TypeError: 'undefined' is not an object (evaluating 'Package["service-configuration"].ServiceConfiguration')
I have no idea how to tackle this problem. Any help appreciated.
EDIT
NGINX is not the problem. The same behavior if I access meteor server directly.
Running "meteor add service-configuration" does fix the above mentioned error, but the absence of the error does not fix the observed behavior, that the app does not render on EC2 whereas it does render when started on localhost. (The error message was the only visible difference between EC2 and localhost. So I suspected that would be the cause. Now that hypothesis must be wrong.) So the problem still persists.
Problem Solved. The Lesson:
Meteor has a debug mode and a production mode. The two may behave differently. On localhost, meteor runs in debug mode per default. On deploy to meteor.com or per mup, the default is production mode. To run meteor in production mode on localhost, run meteor --production.
It looks like you're trying to access the service-configuration configs on your browser.
These are not available client side. This also affects your localhost app but it doesn't break your app (doesn't give you a blank page) because meteor is in debug mode.
In debug mode Meteor files are not concatenated so an error like this would go unnoticed, even if it is thrown on your js console. In production mode the error would halt the rest of your script (since everything is concatenated into a single file)
You need to ensure the code that is doing this only runs on the server side. In general it's not a good idea to have access to the service configuration data on the client side.
Looks like Arunoda and crew are adding a buildOptions.debug setting to the next version of MUP, which should allow you to deploy via MUP and have it act like it's running on localhost. See Arunoda's answer to a related question and (at least for now) documentation for the development version of MUP.
I'm trying to use EQATEC Profiler to profile my ASP.Net app. I followed the instructions listed here. It worked the first time, but every since then, when I run my app, I don't get a "Profiled app started" message. Then when I click on the "Take snapshot" button, I get the following:
"Taking snapshot ...failed: The remote server returned an error: (404) Not Found."
Why can't it find my app?
If a profiled app encounters errors it will log these to the profiler.log file. By default you will find this in C:\Windows\Temp\EQATECProfilerLogs. Try to see if it holds some clues. You can also try to enable "Full logging" in the app options, which will at least output something to the log.
A profiled app is actually the "server" when talking to the profiler; it is the profiler that connects to the app, not the other way around. In your case it seems that the old app has stopped listening (otherwise the profiler's attempt to connect would simply be served by the old app), but the new app has not (could not?) started listening.
It seems strange, though, so my best suggestion is to examine the log-file. It will e.g. show if the app could not start its control-server and if so, why not.
1) Try rebuilding (in Equatec) your application. Make sure "enable runtime control" is enabled in the application options when you build.
1a) Try changing the port being used for runtime control.
2) Run your application through Equatec
3) Check if you have anything funny for firewall settings or similar. Some firewalls treat Equatec communication as traffic to be blocked.
4. If all else fails, just close your application normally. Even if taking snapshots fails, you can still see the profile once your application is closed.
Guess I should provide an update on this. The error was resolved once I downloaded the latest version.