I followed a tutorial how to setup a basic front-end and back-end app (post) in an ACA environment, as follows:
a. backend - python-fastapi (I've implemented CORS related config to enable it)
b. frontend - old school html, using fetch to get and post POSTS(Ingress - External)
Here is the problem, the whole thing works if the backend is in ingress-external/public but once I changed it to ingress-internal (within Container Apps Environment only) and accordingly I will change the api url in the frontend (with the internal keyword), I'm getting CORS error.
Any idea?
Related
After changing the domain name, Keycloak is still trying to authenticate using the old domain name. I'm using the Keycloak version 16.1 with KeycloakJS on the frontend using PKCE, on a server that runs everything in docker containers behind an Nginx reverse proxy.
I have changed all the references of the old domain to the new one, but it still redirects to the old domain:
https://auth.old-domain.com/auth/realms/dev-realm/protocol/openid-connect/3p-cookies/step1.html
All the other resources are requested from the new domain, except the step1.html, which is calling the above link.
Any idea of what may be the culprit?
Found the problem. It's not related to Keycloak.
Even though I have changed the auth URL in the frontend application to the new domain, the CI/CD pipeline wasn't updating the docker image for the frontend application, so it used the old image that had the reference to the old domain.
I would like to use a docker compose file to deploy multiple public end points for our Linux hosted site.
We already have a deployed site that has images stored on a private ACR and is hosted on an Azure App Service (using Web App for Containers). It is deployed via Azure DevOps and works well.
We would however, like to use the same site to host an additional component, an api so that we would then end up with these endpoints:
https://www.example.com - the main site
https://www.example.com/api - the api
We would like to avoid a second app service or a subdomain if possible. The architecture we prefer is to use the same https certificate and ports (443) to host the api. The web site and api share a similar code base.
In the standard app service world, we could easily have deployed a virtual directory to the main app which is simple enough.
This model though seems to be more complicated when using containers.
How can we go about this? I've already had a look at this documentation: https://learn.microsoft.com/en-us/azure/app-service/containers/tutorial-multi-container-app. However, in this example, the second container is a private one - which doesn't get exposed.
Should we use a docker compose file (example please)? Or alternatively, is there a way we can use the Azure DevOps task to deploy to a viritual directory in the way that i would like. This is the task we are using for the single container deployment:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-containers?view=azure-devops
For your requirements, the Web App For Container is also a type of Web App service, and as you see, it only can expose one container to the outside(the Internet) and others are private. So if you want to use the multi-containers Web App to deploy the images to access multiple endpoints such as the main site and the API site, then it's impossible to make your purpose come true.
According to the feature of the Web App that it only exposes one container to the outside, what you can do to achieve your purpose is that creates only one image and route to the endpoints yourself in the code or through a tool, such as the Nginx. Then deploy it to the Web App for Container. Only in this way, you can access multiple endpoints from only one App service..
I created a Rest-API and a frontend as a self contained system with Quarkus.
The frontend is served statically.
For Authentication i use a kleycloak server and have nearly the same configuration as in this guide from quarkus.
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
With this config i need to authenticate for the rest-api and the frontend. Thats what i want.
If i try to load the index.html i got redirected to keycloak and back. That works perfectly.
The problem is, that the same thing happens with the rest-api. I got redirected to keycloak with a "302 found"-status code. Here I would like to have an authentication with a bearer token and no redirect. Quarkus has the following configuration for this:
quarkus.oidc.application-type=service
That collides with the configuration for the frontend. Is there a way to use both, one for static files and one for the rest-api?
If I'm not wrong you're looking for a multi-tenant oidc setup(even though you're not designing tenants). The guide and example can be found on the official quarkus website here.
This way you'll have similar setup:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
quarkus.oidc.restapi.auth-server-url=http://localhost:8180/auth/your/path
quarkus.oidc.restapi.client-id=backend
quarkus.oidc.restapi.application-type=service
P.S you can replace restapi with more likable name.
I’m currently experimenting on Metaflow. I followed the documentation and was able to deploy an aws setup with the given cloud formation template.
My question is why is that I’m always getting a:
message: "Missing Authentication Token"
when I access METAFLOW_SERVICE_URL in the browser, even if I made sure that the APIBasicAuth was set to false during the creation of cloudformation?
Shouldn’t this setting make the metadata/metaflow service accessible without the authentication/api key?
How can I resolve this? Or is this expected? That is, I cannot really view the metadata/metaflow service url via browser?
Thanks in advance
This was resolved under this github issue.
You still need to set the x-api-key header if you are trying to access the service url via the browser. To get the api-key you can go to the aws console
Api Gateway -> Api Keys -> show api key
Alternatively you can use the metaflow client in the sagemaker notebook which should be automatically setup for you via the template.
Also worth mentioning that there are two sets of endpoints: The one provided by the api gateway (which you seem to be hitting) and the one provided by the service itself. The api gateway forwards the requests the the service endpoints but needs the x-api-key to be set in the header. You can probably try hitting the service endpoints directly since you disabled auth.
After going through walkthroughs I had a test mvc app, test web api, and identityserver3 all working perfectly on my machine. I deployed IdentityServer3 to our servers in AWS behind a load balancer. I followed all the instructions in the Deployment wiki. I am able to hit the .wellknown configuration fine after deployment from a browser on my machine.
I changed the authority url for the mvc and api test apps to point to the aws deployment. Clients, Scopes, users, etc are all configured identically as they are hitting the same database as it was when running on local machine.
I can get an access token using RequestResourceOwnerPasswordAsync just fine so I think ids is installed fine.
However, both the API and the MVC app just trying to use implicit flow are now failing. FOr instance, when I try to hit a mvc controller action marked with [Authorize] I get an error stating "An invalid request URI was provided. The request URI must either be an absolute URI or BaseAddress must be set".
If I try to hit the webapi from the mvc app (both running locally on my machine) after a successful RequestResourceOwnerPasswordAsync call, I get the error "Response status code does not indicate success: 401 (Unauthorized)." after what seems like a timeout.
Any help would be greatly appreciated.
Figured out the problem. When specifying PublicOrigin, it has to be a full URL and not just the domain. I had left off https:// prefix.
The web api issue was related to connectivity to the identity server. There was some incorrect proxy settings for the app.