I deployed an application (let's say app1) in GKE with a service, deployment and certificate setup in an existing cluster with Jenkins and another app (let's say app2).
The other app is deployed in the same way as the new one, with a certificate (and a static IP and DNS entry).
Jenkins is not exposed to an external IP, so I used to use the port forward option in the cloud console and then web preview - this creates an appspot URL which alloww me to login to the web admin.
Something strange happened after I deployed app2.
I tested it with the webpreview button and could reach it.
All was fine and it was accessible at the new URL with HTTPS and all.
But after that, the web preview to Jenkins was not working anymore.
Instead, I would be redirected to app2, always.
I could not figure out why, so I removed everything from app2 and now I have some very strange situation:
in the (Chrome) browser where I did most of the actions, I can still access the (broken) app on both the FQDN in DNS and on the appspot link ( https://8080-dot-1234567-dot-devshell.appspot.com/ even after I reboot, clear cache and logout the google account (and removed the statis IP even) - the port forward actions works and gives the above link (with other numbers)
in another (Chromium) browser on the same laptop running Ubuntu, the portford action works, but when clicking the link in the browser it does not generate another appsot url and fails with a 500 error screen
After reading up a bit, I understand there is some proxy that is used to do the forward, I expect the proxy to be 'hanging' some how and on top of that it seems there are application left overs in the cluster that should really not be there
I have basic support currently, so not eligable for technical support.
I cannot find a manual way to access the appspot proxy and I found no load balancer or any other thing I know of that may cause this.
If I run the portfoward in the cloud shell in the second browser, I can curl to the localhost on the exposed port and get Jenkins, so that part seems to work, but the web preview then does not.
How can I go about troubleshooting this (meaning getting back to the web preview working for Jenkins and getting rid of the application left overs)?
I actually found the cause of this issue with the help of a colleague.
The second application I deployed was Yopass.
It turned out that it uses a serviceworker, that cached (almost) everything in the browser, including most of the application, I suppose to run offline.
Although I tried clearing cache in the network tab in developer options, I still had this behaviour which made me think it was not a cache issue.
After removing all cache in the applications tab for both the FQDN url and the appspot domain, behavior went back to normal.
I was not able to fix it in the other browser yet, but I suppose that is cache too. Thanks for the help, I consider this solved.
Related
Background: I'm trying to send a request through cy.request and I get a different response from what I receive when I send a presumably similar request through PostMan. According to the debug information that Cypress writes to the console, I couldn't spot the difference. Therefore I wanted to look at Fiddler and see if I can spot the difference when looking at the raw requests side by side.
However, when I opened Fiddler I realized that I don't see any traffic from it, including the navigation to the home page using cy.visit().
Any ideas why I can't see the traffic in Fiddler, and if there's some way to capture it?
Fiddler is a proxy, it has to be explicitly used by an application, otherwise it will not be recogized by Fiddler.
There are three reasons that often cause that traffic is not visible in Fiddler:
The Windows application explicitly ignores the Windows/IE proxy settings. Usually such apps have an own proxy configuration. Configure it manually to use Fiddler. A common example of such an application is Firefox.
If you have activated the "Act as system proxy at startup" Fiddler changes the proxy settings while running. Any application that is already running when Fiddler starts may have already cached the old proxy configuration and therefore does not use Fiddler. Therefore start Fiddle before any program you want to capture.
The setting "Act as system proxy at startup" is AFAIK user specific, therefore any apps running on a different user or service account are not affected. You have to manually configure them to use Fiddler.
Cypress does not actually make an XHR request from the browser. Cypresd making the HTTP request from the Cypress Test Runner (in Node). So, you won’t see the request inside of your Developer Tools or filddler
I'm using Eclipse to develop an app that consists of an Angular 2 front end and a Java REST back end.
For the front end, I'm using the Angular CLI plugin, which starts the app by issuing an ng serve command to the CLI. This command sets up an http server on port 4200.
For the back end, I'm using an in-company framework that launches in Jetty within Eclipse in port 8088.
While both these ports are configurable, by nature of the frameworks and plugins in use, they'll always be distinct.
Authentication works via an OAuth2 service that is also deployed to port 8088, as part of the framework. This service sets a cookie which certifies the browser session as authenticated. I have verified that this service works correctly by testing it against a Swagger instance of the REST API (also running in 8088 as part of the same framework).
The problem is that when the browser is aimed at the Angular 2 app on :4200, its internal REST API requests to :8088 aren't carrying the authentication cookie. Presumably, this is because of cross-site protection.
Is there any way for the app or the framework to tell the browser that these two "sites" are actually part of the same system?
Alternatively, if I have to configure the dev browser (Chrome) to work, I can live with that too. However, I've tried the --disable-web-security --user-data-dir recommendation, but the cookie still doesn't show up on the requests.
Lastly, I have Apache installed on the dev machine. If I can set up appropriate vhosts and use it as a proxy so that the browser thinks it's all the same, that would probably work too. It would just be a matter of intercepting all /swagger and /api requests and sending them to :8088, and all forwarding all other requests to :4200. However, I've been banging my head against mod_rewrite and mod_proxy and haven't been able to come up with anything that works.
I think what you're looking for is
withCredentials = true
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
I have been trying to deploy a product version of my django application. For that, I have been informed that I must follow the following tutorial: https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-14-04
to setup and run my application on nginx server using gunicorn. I followed all the steps and everything went fine. But in the end of this tutorial it says that:
If no errors are reported, go ahead and restart Nginx by typing:
sudo service nginx restart
You should now be able to go to your
server's domain or IP address to view your application.
but when I go to my ip address, I see the default nginx page. Screen shot here:
screenshot
Can anyone advise, what can I do to see my actual website from here by visiting my ip address in browser?
Try restarting gunicorn service also. I would suggest using automated deployment methodology rather than manually doing it, like dokku, mina etc.
We recently changed the IP-address on a server hosting one of our services based on .NET Web API 2.
The service is using OAuth2, providing external logins via Facebook/Google.
We're still using the same server and the same host name for our services, only the IP-address has changed. Now I'm getting back my login URL with "&error=access_denied" whenever I try to login using Facebook/Google.
I have checked every setting in both Facebook's and Google's developer consoles but nothing seems to apply. If I remove the OAuth redirect URI, I get an error that the URL is blocked, so the settings seems to take effect.
What have I missed?
Funny how asking a question makes you think even more outside of the box. The culprit was that wrong DNS-server was set on the web host.
I'll see myself out...
I have an issue with appears to occur randomly (however i suspect it occurs when starting up the application or changing the application settings). The error I'm getting is as follows:
An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80
The particular error in my case occurs when trying to generate a authentication token using Identity Framework by making requests to the following url:
https://domainname/api/token
Note that the api/token url is specified within the owin pipeline > OAuthAuthorizationServerOptions > TokenEndpointPath. This get set on startup of the application.
From my understanding 127.0.0.1:80 is azures localhost and is forbidden for us to access, i'm not sure why its defaulting to localhost as a domain, my educated guess is something is happening during the startup that's first setting the host to localhost.
My question is does anyone else get this on startup (while the site is warming up) for azure web apps?
Have i configured something incorrectly for me to be getting this behavior?
I know this is a little open ended but is there anything i can do to resolve this issue?
That is the well-known issue described in the official documentation. You may not to access not just a 127.0.0.1, but i suspect that the problem is even a little different - it looks like something is wrong with the :80 port usage. IIS use that port, and i would try to change the port used by your app.
However, from your description is not clear who is that guy who tries to do that - your app tries to do something with the 80 port, or the Azure WebApp functionality.
Please try to start from the eliminating the possibility of some renewing events by enabling Always On in the Azure Web App setting. It will make your web app always on, and will help to understand if that is caused by the service.