Im running my nextjs (UI only) application on localhost http://localhost:3000/, this localhost has to connect to BE API (another hosted service) say https://test-api/api/graphql. This API is called from FE on path http://localhost:3000/api/graphql which connect to https://test-api/api/graphql with the help of nextjs rewrite function
async rewrites() {
const rewrites = [];
rewrites.push({
source: "/api/graphql",
destination: "https://test-api/api/graphql",
});
return rewrites;
},
Now looks like my BE api https://test-api/api/graphql is doing a force direct for path http://localhost:3000/api/graphql to https://localhost/api/graphql
And now since https://localhost/api/graphql is not existing, I'm unable to connect to the BE API. Any idea what can i do in nextjs config so that even if redirect is happening I'm still able to connect to my BE API
Facing this issue only on local environment, hosted nextjs application is not having this issue as it is already on https
Related
abp version 6.0, tiered (.Web, .HttpApi.Host, .AuthServer), MVC.
The following messages appear in .AuthServer.
Client validation failed because 'https://webpage_url/signin-oidc' was not a valid redirect_uri for AppName_Web.
The authorization request was rejected because the redirect_uri was invalid: 'https://webpage_url/signin-oidc'.
How to properly set appsettings.json in .Web, .HttpApi.Host, .Web and .DbMigrator projects for deployment into containerized environments?
Where should be set internal (k8s) url address for auth server and when outer url (which is accessible via internet).
Url https://webpage_url/signin-oidc in the log is outer address (which is accessible via internet).
changing appsettings.json
Client validation failed because 'https://webpage_url/signin-oidc' was
not a valid redirect_uri for AppName_Web. The authorization request
was rejected because the redirect_uri was invalid:
'https://webpage_url/signin-oidc'.
Probably your redirect uri is not seeded, You can check your database if the redirect uri is added correctly for that client (application).
How to properly set appsettings.json in .Web, .HttpApi.Host, .Web and
.DbMigrator projects for deployment into containerized environments?
Where should be set internal (k8s) url address for auth server and
when outer url (which is accessible via internet).
Url https://webpage_url/signin-oidc in the log is outer address (which
is accessible via internet).
You don't change the redirect uri based on your deployment environment. It should point to a valid reachable endpoint that the openid-provider redirects to after signin.
As far as I understand, apart from normal login flow, you are having problems when interacting to openid-provider in isolated network (k8s, docker).
Since you have auth-server on real domain endpoint (like https://my-authserver.com), you are getting error from containers that tries to reach to domain (https://my-authserver.com/.well-known/openid-configuration) and you receive SSL error or not found error.
So you want internal requests done to the internal container (like http://my-auth-container/.well-known/openid-configuration) while user interacted login/logout should be done using the public domain name (https://my-authserver.com).
Instead of changing the public issuer, you can add OpenIdConnectOptions based on your deployment to configure MetadataAddress as:
context.Services.Configure<OpenIdConnectOptions>("oidc", options =>
{
options.MetadataAddress = configuration["AuthServer:MetaAddress"].EnsureEndsWith('/') +
".well-known/openid-configuration";
var previousOnRedirectToIdentityProvider = options.Events.OnRedirectToIdentityProvider;
options.Events.OnRedirectToIdentityProvider = async ctx =>
{
// Intercept the redirection so the browser navigates to the right URL in your host
ctx.ProtocolMessage.IssuerAddress = configuration["AuthServer:Authority"].EnsureEndsWith('/') +
"connect/authorize";
if (previousOnRedirectToIdentityProvider != null)
{
await previousOnRedirectToIdentityProvider(ctx);
}
};
var previousOnRedirectToIdentityProviderForSignOut =
options.Events.OnRedirectToIdentityProviderForSignOut;
options.Events.OnRedirectToIdentityProviderForSignOut = async ctx =>
{
// Intercept the redirection for signout so the browser navigates to the right URL in your host
ctx.ProtocolMessage.IssuerAddress = configuration["AuthServer:Authority"].EnsureEndsWith('/') +
"connect/endsession";
if (previousOnRedirectToIdentityProviderForSignOut != null)
{
await previousOnRedirectToIdentityProviderForSignOut(ctx);
}
};
This way, login/logout requests will be redirected to the configuration["AuthServer:Authority"] which should be a public domain (like https://my-authserver.com) and the internal requests will be redirected to the configuration["AuthServer:MetaAddress"] which should be an internal service (like http://my-auth-container)
For more details, check out:
eShopOnAbp Public-Web application configuration
eShopOnAbp Azure deployment configuration
hope you are all good.
I'm facing an issue with my frontend instance.
Actually, we have a frontend hosted and secured by OpenVPN credentials. That means, no one can access it without a connection to our VPN. That configuration works well, but still one issue with axios proxies.
Quick notes:
we are not using server-side rendering
frontend hosted in AWS CloudFront
backend deployed to AWS EC2 instances
This is the current configuration in my nuxtjs frontend nuxt.config.js file:
{
...,
proxy: {
'/api/': {
target: !process.env.FLAVOR
? 'http://localhost:8009'
: (process.env.FLAVOR === 'production'
? 'https://api.domain.tld'
: 'https://' + process.env.FLAVOR + '-api.domain.tld'),
pathRewrite: { '^/api/': '/v1/' }
}
},
...
}
This solution helps me to avoid all environments easily, without setting each URL inside my environment variable in Dockerfile, and also the CORS policy.
In that way, if I check the console inspector and verify the network tab, I got access denied because not connected to the client. How do VPN and proxy really work? Are the requests called client-side or server-side?
Thanks by advance for helping me.
I am setting up a community website with a Strapi CMS backend and a NuxtJS frontend using the composition API.
Besides the normal registration and login using email and username (which works!), I want users to be able to login using GitHub.
I am using #nuxtjs/auth module for authorization.
I've "deployed" my Strapi backend using ngrok. This is needed apparently to make OAuth work.
I've set up my GitHub application, using <ngrok-url>/connect/github/callback as the callback.
I've set the GitHub client_id and secret in my .env file.
In the strategies in my nuxt.config.js file I have this:
github: {
clientId: process.env.GITHUB_CLIENT_ID,
clientSecret: process.env.GITHUB_CLIENT_SECRET,
},
I've added a line in config/server.js of the Strapi backend:
url: '<ngrok url>'
So the backend is fired up in that location.
In my Strapi configuration, I've enabled a GitHub provider, and I need a redirect url to my frontend there. I am not sure what to put here.
I've tried: http://localhost:3000 (my Nuxt app port), but then I get a redirect uri mismatch error ("the redirect uri must match the registered callback"), when I try to access it from the frontend (using nuxt-auth's loginWith('github)').
More info on this here, but I don't get what they are saying.
Provide a redirect_uri where?
And they say to have a redirect_uri that matches what you registered. That matches what exactly?
The nuxt-auth docs are not that elaborate, saying to use $auth.loginWith('github') and that's it. I do this in my frontend, but I'm not sure if that is all I should do.
I can go manually to "<ngrok-url>/connect/github" (in ingognito) and login there in GitHub and I get redirected to the url I put in Strapi, with the access token as a parameter. So that part seems to work.
My main 2 question are:
How do I make the correct call from the frontend to the right endpoint to login through GitHub?
How do I process the result of that call?
Any help is much appreciated!
Update #1
I added a property redirectUrl on the github strategy in nuxt.config.js with the <ngrok-url>/connect/github/callback. That fixes a redirecting issue from GitHub.
I also added a redirect in Strapi to localhost:3000/connect/github and added a page in nuxt following this solution.
Now, I get back a jwt token and a user from Strapi, but $auth.loggedIn is still false in my front end. I'll try to fix this by writing my own middleware. I think this is needed because the app is server-side rendered.
The issue was that loginWith('github') connects nuxt directly to github. But we want to go to Strapi first. So in the end, I removed all the github-related info in my frontend and made a regular <a> with href to <strapi-url>/connect/github and then handled the response in a vue page like so:
data() {
return {
provider: this.$route.params.provider,
access_token: this.$route.query.access_token,
}
},
async mounted() {
const res = await this.$axios.$get(
`/auth/github/callback?access_token=${this.access_token}`,
)
const { jwt, user } = res
await this.$auth.setUserToken(jwt)
this.$auth.setUser(user)
this.$router.push(`/`)
},
To test it locally, I used ngrok to fire up the backend in a tunnel, instead of localhost.
If you want to look at more code, check out my PR here
I am getting a 401 and some cross domain issues when trying to access IBM Weather REST API from either client (browser) or server.
If I generate a URL and try and access it directly from a browser (eg paste it in it works fine and the JSON weather report is returned).
When I try and run the Javascript HTTP request from either the browser or server it seems like it's only allowed to run from an ibm.com domain.
Failed to load https://twcservice.au-syd.mybluemix.net/api/weather/v1/geocode/-33.00/151.00/forecast/daily/7day.json?units=m&language=en-US: The 'Access-Control-Allow-Origin' header contains multiple values 'https://*.ibm.com, https://*.ibmcloud.com', but only one is allowed. Origin 'http://localhost:3000' is therefore not allowed access.
I am using the free service on Bluemix. Is this restricted to only run via a Bluemix server? or are there some options I can pass when I create the service on Bluemix
Note, when I make the request I am using the credentials supplied via the Bluemix console. Again, this works via the browser URL bar, but not via code.
Update/More info: if I hit past the URL above into the browser (with creds) it works as above, then if hit it via the web app in the same session it works.
Hmmm. So the IBM server is sending the following response header:
Access-Control-Allow-Origin: https://*.ibm.com, https://*.ibmcloud.com
That's an invalid response from IBM. Unfortunately, I think your only option is to complain to IBM, and convince them to
Return a valid Access-Control-Allow-Origin response header (with only one value)
Allow people outside of IBM to access it
Without that, I fear you're out of luck.
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.