Does anyone has experience hosting piranha on ubuntu in a docker container behind nginx?
The frontend is fine, everything works smooth. But the manager is not working for me. It has something to do with the login. First i saw error 502 after login (failed login was working with correct error message, so the post itself is working). I changed the login not to do the local redirect but returning the page. No error message, so i guess the login data was fine, but somehow i am still not logged in.
The only cookie i see is the antoforgery. Someone has an idea, the is no error message in the logs.
The problem was, that aspnet core identity created a cookie larger then nginx accept in proxy communication.
I increase the buffers, but this did not work for me. There are a lot of article about it, but nothing worked.
So i decided to reduce the header sent. The application configuration has been changed to manage the identity in a different way. More information in memory but smaller cookie.
Related
I have two cloud services up and running.
frontend (URL: https://frontend-abc-ez.a.run.app/)
backend (URL: http://backend-abc-ez.a.run.app/)
Frontend is calling the backend through a nuxt.js server middleware proxy to dodge the CORS problematics.
The call is coming through - I can see that in the backend log files. However the response is not really coming back through because of CORS. I see this error in the console:
Mixed Content: The page at 'https://frontend-abc-ez.a.run.app/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://backend-abc-ez.a.run.app/login'. This request has been blocked; the content must be served over HTTPS.
What I find weird is that I configured the backend url with https but it is enforced as http - at least that is what the error is telling me. Also I see a /login path segment in the unsecure URL. Why is that? I never explicitly defined that endpoint. Is it the security layer proxy of the run service itself?
Anyway - I need to get through this properly and am having a hard time to understand the source of the problem.
For some reason as I rechecked the applications today in the morning everything went fine. I have really no idea why it is working now. I did not change a thing - I waited for the answers here before I'd continue.
Very weird. But the solution so far seems to be waiting. Maybe Cloud Run had some troubles.
I'm attempting to use Keycloak for some future projects and it's still very new to me so I'm plugging away reading through the docs and searching for issues online but I'm currently stumped on one thing - I have a vuejs app I’ve added as a client (127.0.0.1:3001), I have a reverse proxy setup in IIS (idp.mc.local) and then a docker container on Windows with keycloak running (127.0.0.1:8080), when I attempt to login, instead of being redirected back to the vuejs client I am just getting redirected to the root of the reverse proxy with the state value in the url, as in the network logs in the screenshot below:
Network logs showing incorrected 'Location' redirect
If I don’t set a front end url for the realm and bypass the proxy / hook my vuejs client to login via Keycloak directly on 127.0.0.1:8080, it redirects to 127.0.0.1:3001/#state… correctly, as below:
Network logs showing correct 'Location' redirect
I can't spot any way to sort this issue, I thought the front end url for the realm should state the proxy address? I can't see why Keycloak would redirect to it at the end of the login process rather than to my client app url, the redirect_uri is being ignored by keycloak and for some reason taking me back to the root of my proxy domain. If I actually manually visit 127.0.0.1:3001/#state… with the state value copied in from the incorrect redirect, I log in successfully.
It's baffling me and any help would be appreciated!
The answer did turn out to be an IIS related issue with the setup of Application Request Routing / ARR being the problem. What was needed was to edit the settings for IIS Application Request Routing and uncheck the option:
Reverse rewrite host in response headers as can be seen in the image below:
IIS ARR Checkbox to untick
Hopefully this will be helpful for someone else who might have the same issue at some point!
I created a custom domain mapping for my Cloud Run service following this guide https://cloud.google.com/run/docs/mapping-custom-domains.
I can access my service via the https run.app URL and the custom domain via HTTP, but when I go to the custom domain via HTTPS, I get back a Google 404 error page.
The weird thing is, this seems to be an issue on my local laptop (both browser and curl on the terminal), but curl-ing it from a remote server seems to work ok.
As #LundinCast pointed out, there seems to be an outage on the Google server side. I'll monitor the situation and mark this as resolved for now.
Edit: I'm guessing this is related to https://status.cloud.google.com/incident/cloud-networking/19016
I have a PWA site which is working fine on Firefox, Chrome and Edge on Windows, and all of those on Android, Edge (EdgeA).
The problem
This much I know from looking at my Azure server logs:
(1) The login POST is hits a Core 2.2 controller which does the authentication and returns 302 along with a standard Core 2.2 cookie set including the authentication token for the user.
(2) The EdgeAndroid browser receives that, and immediately GETs the location specified.... except this GET doesn't include the cookies from (1), so the Core 2.2 system responds with a 302 back to the login page.
It's a redirect loop.
-> EdgeA is eating my cookies!
I can run this perfectly on the above browsers, and the logs show Edge/Windows for example has the (1)(2) sequence exactly as you'd expect, with the cookie credentials in the second request.
The only thing different is Edge Android. I stripped out all the caching from my service worker for that browser and it's still broken - I think I may need to just not run the service worker for it at all.
... and my questions are:
Does anyone have a PWA which actually works in EdgeA?
Does anyone have any idea what I may have missed? Note it's just this one browser which is broken, hence it may be them not me.
In case it is them not me, is there a place I have not yet googled where I can report defects in this possibly minor-interest browser?
This sounds similar, although that's cross-domain, and my 302 is not cross domain.
I think this was caused by the Edge Android Browser interpreting the display:standalone directive and consequently opening a "stand alone" window, which does not carry over the cookies from the original browser.
The server logs show that the EdgeA client "drops the cookies" when handling a "login successful" 302 response from the standard Core 2.2 login stuff.
My work around is to serve a specific manifest.json to the EdgeA browser, so that it reads display:browser.
At the same time I fixed this MS released a new version of EdgeA, so I can't be 100% sure if my change fixed this or if they actually listened to my whining.
I'm trying to build an hotspot with mikrotik to allow the internet to my clients! So, the problem starts when i'm trying to access sites with Https sercurity like facebook, before the user authenticates.
With normal http connection the hotspot works fine, but when i put https, i'm getting this error: error
Can someone please help me? I have read all the docs in the mikrotik forum, nothing worked!
it's good news that nothing worked because it's the purpose of HTTPS: ensure that the site you want is the site you get. Hotspot does exactly the reverse: you ask for a website and you get another one (hotspot landing page): error.
There is no workaround without installing your certificate on each client, which is not doable on a hotspot environment.
Hopefully, problem has been handled with CNAs (Captive Network Assistants) which detect hotspot presence and launch an automatic HTTP request before the user has time to launch its own browser and navigate to Facebook. Latest iOS/Android/Windows versions do that automatically.