I've got a Next.js application that uses AWS Cognito userpools for authentication. I have a custom UI and am using the aws-amplify package directly invoking signIn/signOut/etc... in my code. (I previously used the AWS Hosted UI and had the same problem set out below - I hoped switching and digging into the actual APIs who reveal my problem but it hasn't)
Everything in development (running on localhost) is working correctly - I'm able to login and get access to my current session both in a page's render function using
import { Auth } from 'aws-amplify';
...
export default const MyPage = (props) => {
useEffect(async () => {
const session = await Auth.currentSession();
...
}
...
}
and during SSR
import { withSSRContext } from 'aws-amplify';
...
export async function getServerSideProps(context) {
...
const SSR = withSSRContext(context);
const session = await SSR.Auth.currentSession();
...
}
However, when I deploy to AWS Amplify where I run my staging environment, the call to get the current session during SSR fails. This results in the page rendering as if the user is not logged in then switching when the client is able to determine that the user is in fact logged in.
Current Hypothesis - missing cookies(??):
I've checked that during the login process that the AWS cookies are being set correctly in the browser. I've also checked and devtools tells me the cookies are correctly being sent to the server with the request.
However, if I log out context.req.headers inside getServerSideProps in my staging environment, the cookie header is missing (whereas in my dev environment it appears correctly). If this is true, this would explain what I'm seeing as getServerSideProps isn't seeing my auth tokens, etc... but I can't see why the cookie headers would be stripped?
Has anyone seen anything like this before? Is this even possible? If so, why would this happen? I assume I'm missing something, e.g. config related, but I feel like I've followed the docs pretty closely - my current conf looks like this
Amplify.configure({
Auth: {...}
ssr: true
});
Next.js version is 11.1.2 (latest)
Any help very much appreciated!
You have to use Next#11.0.0 to use getServerSideProps, withSSRContext and Auth module in production.
I had same issue.
My solution was that disconnect a branch has an authentication problem once and reconnect the branch.
What are your build settings? I guess you are using next build && next export in which case this getServerSideProps shall not work. See https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features
To use SSR with AWS amplify see https://docs.aws.amazon.com/amplify/latest/userguide/server-side-rendering-amplify.html#redeploy-ssg-to-ssr or consider deploying on a node server that is actually a server that you can start with next start like AWS EC2 or deploy on Vercel.
Otherwise if you use next export have to make do with client side data fetch only with client side updates only and cannot use dynamic server side features of nextjs.
One reason for context.req.headers not having any cookie in it is because CloudFront distribution is not forwarding any cookies.
This “CloudFront Behaviour” can be changed in two ways:
Forward all cookies, OR
Forward specified cookies (i.e. array of cookie names)
To change the behaviour, navigate to CloudFront on AWS console > Distributions > your_distribution > Behaviors Tab.
Then Edit existing or Create new behaviour > Change cookies settings (for example set it to "All")
Related
I'm testing a local zoom app build. To be specific, zoom docs differentiate their app types, and what i want is a web view opened in the zoom client app view, therefore what ive developed is technically referred to as a "Zoom App" (more info here)
In the zoom docs, it mentions you cant setup the redirect urls to be localhost:8080 for example, it has to be set up with ngrok or a public url (more info here)
So ngrok is properly working (setup with cli command ngrok http 8080 ). I also tried this command with other values set for the --host-header flag. some attempts include --host=header=rewrite, --host-header=localhost, and --host-header=localhost:8080
Express server on :8080, react client on :3000
Express is linked into multiple oauth providers, google and zoom are 2 examples. google integration is working properly with the same oauth middleware, and route controllers on the api side (but google integration doesnt require the ngrok setup)
with zoom, and the ngrok setup, the request to the /callback route once the user confirms the zoom authorization, everything works fine, except the cookie that is returned by the server setting the header set-cookie is not set into the browsers application storage. nothing is registered in the cookies tab for oauth that goes through ngrok
the very next request confirms no cookie is stored, as there is no cookie: ... header in the request. interestingly, there are no errors on this cookie that is sent in the initial response headers of the servers /callback endpoint
Oauth Requests through Ngrok:
Oauth Requests without Ngrok:
Heres the controller that run after successful oauth verification/tokenization, triggered in both cases:
const oauth = catchAsync(async (req, res) => {
const user = req.user;
const tokens = await tokenService.generateAuthTokens(user);
res
.cookie('refreshToken', tokens.refresh.token, {
maxAge: tokens.refresh.maxAge,
httpOnly: true,
sameSite: "none",
secure: true,
// domain: "8796-2603-6011-223-7a04-2830-4c71-6f20-54c0.ngrok.io" // test
})
.redirect(`${config.clientURL}/app`)
});
I tried manually setting the domain value of the cookie config. Some values i tried include
localhost
localhost:8080
some-ngrok.io
, but to no avail
Heres the devserver webpack config, which usually has nothing extra, although i did also try with all for allowedHosts
But Im hopeful for a solution that works in both production and development
module.exports = {
// Extend/override the dev server configuration used by CRA
// See: https://github.com/timarney/react-app-rewired#extended-configuration-options
devServer: function (configFunction) {
return function (proxy, allowedHost) {
const config = configFunction(proxy, allowedHost);
// config.headers = {
// // "Cross-Origin-Embedder-Policy": "credentialless",
// // "Cross-Origin-Opener-Policy": "same-origin",
// // 'Cross-Origin-Resource-Policy': 'cross-origin',
// // 'Access-Control-Allow-Origin': '*'
// };
config.allowedHosts = ['all']
return config;
};
},
};
So maybe this is just a development environment issue? After all, google oauth works fine in prod/dev, maybe its just ngrok. So i've tested this by adding my live api url to the oauth redirect/allowedhost in zoom app web portal and ran this in production, and got the same issue.
Any one else go through this with a zoom app?
Edit:
After investigating this further, it seems cookies are sent correctly on most API requests. However something happens in the specific request that checks if the user is logged in and it always returns null. When refreshing the browser a successful preflight request is sent and nothing else, even though there is a session and a valid session cookie.
Original question:
I have a NextJS frontend authenticating against a Keystone backend.
When running on localhost, I can log in and then refresh the browser without getting logged out, i.e. the browser reads the cookie correctly.
When the application is deployed on an external server, I can still log in, but when refreshing the browser it seems no cookie is found and it is as if I'm logged out. However if I then go to the Keystone admin UI, I am still logged in.
In the browser settings, I can see that for localhost there is a "keystonejs-session" cookie being created. This is not the case for the external server.
Here are the session settings from the Keystone config file.
The value of process.env.DOMAIN on the external server would be for example example.com when Keystone is deployed to admin.example.com. I have also tried .example.com, with a leading dot, with the same result. (I believe the leading dot is ignored in newer specifications.)
const sessionConfig = {
maxAge: 60 * 60 * 24 * 30,
secret: process.env.COOKIE_SECRET,
sameSite: 'lax',
secure: true,
domain: process.env.DOMAIN,
path: "/",
};
const session = statelessSessions(sessionConfig);
(The session object is then passed to the config function from #keystone-6/core.)
Current workaround:
I'm currently using a workaround which involves routing all API requests to '/api/graphql' and rewriting that request to the real URL using Next's own rewrites. Someone recommended this might work and it does, sort of. When refreshing the browser window the application is still in a logged-out state, but after a second or two the session is validated.
To use this workaround, add the following rewrite directive to next.config.js
rewrites: () => [
{
source: '/api/graphql',
destination:
process.env.NODE_ENV === 'development'
? `http://localhost:3000/api/graphql`
: process.env.NEXT_PUBLIC_BACKEND_ENDPOINT,
},
],
Then make sure you use this URL for queries. In my case that's the URL I feed to createUploadLink().
This workaround still means constant error messages in the logs since relative URLs are not supposed to work. I would love to see a proper solution!
It's hard to know what's happening for sure without knowing more about your setup. Inspecting the requests and responses your browser is making may help figure this out. Look in the "network" tab in your browser dev tools. When you make make the request to sign in, you should see the cookie being set in the headers of the response.
Some educated guesses:
Are you accessing your external server over HTTPS?
They Keystone docs for the session API mention that, when setting secure to true...
[...] the cookie is only sent to the server when a request is made with the https: scheme (except on localhost)
So, if you're running your deployed env over plain HTTP, the cookie is never set, creating the behaviour you're describing. Somewhat confusingly, in development the flag is ignored, allowing it to work.
A similar thing can happen if you're deploying behind a proxy, like nginx:
In this scenario, a lot of people choose to have the proxy terminate the TLS connection, so requests are forwarded to the backend over HTTP (but on a private network, so still relatively secure). In that case, you need to do two things:
Ensure the proxy is configured to forward the X-Forwarded-Proto header, which informs the backend which protocol was used originally request
Tell express to trust what the proxy is saying by configuring the trust proxy setting
I did a write up of this proxy issue a while back. It's for Keystone 5 (so some of the details are off) but, if you're using a reverse proxy, most of it's still relevant.
Update
From Simons comment, the above guesses missed the mark 😭 but I'll leave them here in case they help others.
Since posting about this issue a month ago I was actually able to work around it by routing API requests via a relative path like '/api/graphql' and then forwarding that request to the real API on a separate subdomain. For some mysterious reason it works this way.
This is starting to sound like a CORS or issue
If you want to serve your front end from a different origin (domain) than the API, the API needs to return a specific header to allow this. Read up on CORS and the Access-Control-Allow-Origin header. You can configure this setting the cors option in the Keystone server config which Keystone uses to configure the cors package.
Alternatively, the solution of proxying API requests via the Next app should also work. It's not obvious to me why your proxying "workaround" is experiencing problems.
I can't use apollo Studio. After migration for Graphql playground. When I try to run in localhost and redirect me to apollo studio sanbox https://studio.apollographql.com/sandbox?endpoint=http%3A%2F%2Flocalhost%3A5018%2Fgraphql: Unable to connect to localhost.
Please help to solve this
Add CORS configuration options for the server's CORS behavior.
const server = new ApolloServer({
cors: {
"origin": "https://studio.apollographql.com",
"credentials": true
},
typeDefs,
resolvers,
});
Update
I was able to solve my problem. I had added the helmet middleware to Express and just needed to update the contentSecurityPolicy setting.
export default async (app: express.Application) => {
app.use(config.graphqlPath, express.json());
app.use(cors());
app.use(
helmet({
contentSecurityPolicy:
process.env.NODE_ENV === 'production' ? undefined : false
})
);
};
Not sure if that helps since there were not a lot of details on the environment in the original post, but maybe this can help someone else in the future.
Original Post
I'm having the same issue only with Apollo Sandbox. I just get a page stating that I appear to be offline. I checked the console and there are a number of CORS errors.
I also attempted to switch to the GraphQL Playground as a plugin. It displayed the initial loading screen, but never progressed past that point. I checked the console and also saw similar CORS errors.
I'm using apollo-server-express. I've created Apollo servers in the past and have never run into this while trying to run tools locally.
Apollo now supports an embedded version of the Apollo Sandbox & Apollo Explorer that you can host on your Apollo Server endpoint urls. This will remove the need to whitelist the Apollo Studio endpoint in your CORS configuration to use our Explorer. You can use the Explorer right on your server endpoint.
For local development endpoints, pass embed: true to the ApolloServerPluginLandingPageLocalDefault plugin in your Apollo Server config. See more details here.
For production endpoints, pass a graphRef and embed: true to the ApolloServerPluginLandingPageProductionDefault plugin in your Apollo Server config. See more details here.
We've built a framework around Nuxt to get it to work with WordPress really well. We have been pulling our hair out trying to get post previewing working.
A common setup will be a WordPress install running on a domain like http://api.example.com and then to have Nuxt running on http://www.example.com. There is a WordPress plugin called WP-Graph-QL that creates a GraphQL endpoint like http://api.example.com/graphql, and we wrote a CORS plugin to set the correct CORS headers to work with whatever the frontend origin may be. This is that plugin if you are curious https://github.com/funkhaus/wp-graphql-cors
Our Nuxt Apollo setup is this:
export default function() {
return {
httpEndpoint: process.env.DEFAULT_ENDPOINT,
getAuth: () => process.env.BASIC_API_TOKEN || "",
httpLinkOptions: {
credentials: "include"
}
}
}
FYI sometimes the API will be hidden behind a Basic Auth UN/PW (like when on a staging site for example), that is what the getAuth function is doing.
This all seems to work client side, but it fails on SSR for some reason. It seems the cookies don't get sent in the SSR request, but they do in the client side request. Am I missing something super obvious here?
NOTE: I asked this question here 8 days, but am trying here for more attention
I am making a React Native App with a Lumen API as the backend. I want to protect all my routes with a simple middleware. I have modified the AuthServiceProvider to check whether the request has a header with the token, if it does check whether that token belongs to a user.
AuthServiceProvider
$this->app['auth']->viaRequest('api', function ($request) {
if($request->header('access_token')){
return User::where('access_token', $request->header('access_token'))->first();
}
return null;
});
A simple Axios request would look like this,
axios.get('url/to/site', {headers:{access_token: '12345667890ABC'}})
.then(res => console.log(res))
.catch(err => err.response);
The routes are placed inside the auth middleware in web.php file. I know that while working with mobile Apps we don't have to worry about CORS, so that isn't the problem.
Strangely enough the code seems to work on my localhost and authenticates the user, however when I deploy to AWS ElasticBeanstalk it returns unauthorized. I am using the free tier of AWS for now. My instance is running Amazon Linux AMI
I have also tried setting the axios headers as such;
axios.defaults.headers.common['access_token'] = '12345667890ABC';
And just for peace of mind I added some additional headers via another middleware in Lumen as well.
return $next($request)
->header('Access-Control-Allow-Origin', '*')
->header('Access-Control-Allow-Headers', 'access_token')
->header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
I have tested local and AWS routes from Postman as well, both with and without the access_token. The result is the same, it works for localhost but does not work for AWS, where the header access_token is just missing.
At first I thought the problem might be a config or permission issue on AWS but I have also tried the whole process on a simple shared hosting account and the middleware still does not authenticate the request via Postman.
Remove underscores from the header variables, example:- header_var_val = "some value" replace it with --> headervarval = "some value"