I am wondering if it's possible to have separate configurations for GitHub/OAuth for development and production. I'm assuming this is baked it, but I can't find it.
I have a custom configuration that looks something like this:
Accounts.loginServiceConfiguration.insert({
service: "github",
clientId: "19c25aeb2a609872672d",
secret: "07136530fa20c3722caf6c2decc3776ca8729cf2"
});
It works like a dream locally, as the keys were set up for use with localhost. I tried specifying another for production (with no distinction between dev and production in the codebase, just another .insert()), like this:
Accounts.loginServiceConfiguration.insert({
service: "github",
clientId: "19c25aeb2a609872672d",
secret: "07136530fa20c3722caf6c2decc3776ca8729cf2"
});
Accounts.loginServiceConfiguration.insert({
service: "github",
clientId: "9f9e82b7ab0a1e1f3ec1",
secret: "12c1ab66f2c5d37c8c55390d09725c400e1bca84"
});
When I deployed to production, it looks like it's going with the first configuration (localhost).
On server startup (yes, this will be server code), clear all Accounts.loginServiceConfiguration entries. Then reinsert them according to use:
Meteor.startup(function(){
Accounts.loginServiceConfiguration.find({}).remove();
if (process.env.NODE_ENV === "development") {
// Insert all login configs for development
} else {
// Insert all login configs for production
}
}
Related
I'm running into a weird situation here that debugging is becoming extremely hard to debug.
I have made a post here https://forum.cleavr.io/t/cloudflare-caching-in-a-quasar-app/844 thinking that the problem was about caching.
We are having hydration errors in our webapp codotto.com ONLY after a few hours (or minutes depending on website traffic). As soon as I redeploy the app, everything works well. No hydration errors anymore.
We had the idea that it was caching but we have disabled caching completely in our Cloudflare dashboard:
Then we can verify that the cache is not being used:
Note the CF-Cache-Status set to DYNAMIC (refer to here to see that when you have DYNAMIC set in CF-Cache-Status header it means that cache is not being used).
Locally the app works great and we are not able to reproduce the issue locally and in staging as well. This only happens in production. Here we have configurations for pm2 settings:
production
// DO NOT MODIFY THIS FILE. THIS FILE IS RECREATED WITH EVERY DEPLOYMENT.
module.exports = {
name: "codotto.com",
script: "index.js",
args: "",
log_type: "json",
cwd: "xxxx/codotto.com/artifact",
// Note: We detected that this web app is running on a server with multiple CPUs and hence we are
// setting *instances* to "max" and *exec_mode* to "cluster_mode" for better performance.
instances : 1, // change the value to "1" if your server has only 1 CPU
// exec_mode : "cluster_mode", // remove this line if your server has only 1 CPU
env: {
"PORT": 7145,
"CI": 1,
"NUXT_TELEMETRY_DISABLED": 1
}
}
staging
// DO NOT MODIFY THIS FILE. THIS FILE IS RECREATED WITH EVERY DEPLOYMENT.
module.exports = {
name: "staging.codotto.com",
script: "index.js",
args: "",
log_type: "json",
cwd: "xxxxx/staging.codotto.com/artifact",
// Note: We detected that this web app is running on a server with multiple CPUs and hence we are
// setting *instances* to "max" and *exec_mode* to "cluster_mode" for better performance.
instances : 1, // change the value to "1" if your server has only 1 CPU
// exec_mode : "cluster_mode", // remove this line if your server has only 1 CPU
env: {
"PORT": 9892,
"CI": 1,
"NUXT_TELEMETRY_DISABLED": 1
}
}
We are running out of ideas and this only happens in production, making it extremely hard to debug and we are scoping the problem down to the server configuration.
We understand that this question might be tagged as off-topic since it's not too specific but what I'm looking for are some ideas on things that might help debug this issue. The webapp is done using Quasar framework in SSR mode and we are using https://cleavr.io/ to deploy our application.
We have tried following this guide on Quasar's website to debug hydration errors but haven't gotten us anywhere.
In case you would like to reproduce the bug, you will need to sign up to an account in codotto.com, then visit https://codotto.com so that you are redirected to the dashboard instead of the landing page.
Can anyone here help or explain why we have these hydration errors?
The problem was not related to caching or any other issues we thought it was related.
In one of our bootfiles we had the following:
export default boot(({ router }) => {
router.beforeEach((to, from, next) => {
const requiresAuthentication = to.matched.some(
(record) => record.meta.needsAuthentication
);
const appStore = useAppStore();
if (requiresAuthentication && !appStore.isLoggedIn) {
next({ name: 'auth-login' });
} else {
const onlyGuestCanSee = to.matched.some(
(record) => record.meta.onlyGuestCanSee
);
if (onlyGuestCanSee && appStore.isLoggedIn) {
next({ name: 'dashboard' });
} else {
next();
}
}
});
});
In this file we didn't pass the store to useAppStore causing the request pollution and, consequently, hydration errors. The fix was to pass store to useAppStore:
export default boot(({ router, store }) => {
const appStore = useAppStore(store);
...
})
I have an app that authenticates against Azure AD using next-auth 4.
It works fine and I can authenticate.
When I try to configure a custom base path http://localhost:3000/myapp for the app and call signIn() I get a 404 error telling me that http://localhost:3000/api/auth/error is not found.
I have configured all the paths like described below.
What confuses me:
If I use the standard path I notice that [...nextauth.js] gets executed
If I use a custom path, [...nextauth.js] is not even executed
A similar scenario in next.auth 3 worked just fine.
Comparing to next-auth 3 it looks like next-auth 4 does not honor NEXTAUTH_URL.
What can I do?
.env.local
AZURE_CLIENT_ID= ....
AZURE_CLIENT_SECRET=...
AZURE_TENANT_ID=...
JWT_SECRET=...
NEXTAUTH_URL=http://localhost:3000/myapp/api/auth
NEXTAUTH_URL_INTERNAL=http://localhost:3000/mypp/api/auth
NEXT_AUTH_DEBUG=true
APP_BASE_PATH=/myapp
next.config.js:
const basePath = process.env.APP_BASE_PATH;
module.exports = {
reactStrictMode: true,
basePath: `${basePath}`,
};
[...nextauth.js]`
export default NextAuth({
providers: [
AzureADProvider({
clientId: process.env.AZURE_CLIENT_ID,
clientSecret: process.env.AZURE_CLIENT_SECRET,
scope: "offline_access User.Read",
tenantId: process.env.AZURE_TENANT_ID,
}),
],
....
debug: process.env.NEXT_AUTH_DEBUG,
secret: process.env.JWT_SECRET,
});
Did you've tried that solution ?
Try to edit your _app.tsx and define your base path using the props basePath on your , as in that example.
I'm developing a Frontend using NextJS and Keycloak for auth-purpose. After adding Sentry, I'm facing this issue here, where the token endpoint of Keycloak is returning an error; So I can log in.
I've tried many things:
Change the web-origin config of Keycloak, which (obviously) doesn't change or solves the problem
Play with the Sentry client config, without success, because the denyUrls property still make the Sentry SDK send the sentry-trace into the request.
Now I don't have any more Idea, so I coming here for more help.
So after some investigations, I came across this tracingOrigins property that can be set using integrations like this:
integrations: [
new (Sentry.Integrations as any).BrowserTracing({
tracingOrigins: [
process.env.NEXT_PUBLIC_URL,
process.env.NEXT_PUBLIC_BACKEND_URL,
process.env.NEXT_PUBLIC_MATOMO_URL,
],
}),
],
This config is done inside the sentry.client.config.ts file. The downside is that, urls which are not included there, are simply not tracked.
Unfortunately, Keycloak has hardcoded list of allowed headers, so you can't configure Keycloak for sentry-trace header.
You can have some non ideal work arounds:
don't use sentry
compile own hacked Keycloak version, where you allow that header
add reverse proxy in front of Keycloak, which will add sentry-trace header to allowed headers
...
I've solved this issue on a nextJs application by adding the following header to the static sourcemap response.
'Access-Control-Allow-Headers' on next.config.js
const CONFIG = {
headers: () => [
{
source: "/_next/:path*",
headers: [
{ key: "Access-Control-Allow-Origin", value: SHOP_ORIGIN },
{ key: 'Access-Control-Allow-Headers', value: '*' },
],
},
],
}
siteMetadata: {
title: `Gatsby Default Starter`,
description: `Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.`,
author: `#gatsbyjs`,
},
plugins: [
`gatsby-plugin-react-helmet`,
{
resolve: `gatsby-source-filesystem`,
options: {
name: `images`,
path: `${__dirname}/src/images`,
},
},
`gatsby-transformer-sharp`,
`gatsby-plugin-sharp`,
{
resolve: `gatsby-plugin-manifest`,
options: {
name: `gatsby-starter-default`,
short_name: `starter`,
start_url: `/`,
background_color: `#663399`,
theme_color: `#663399`,
display: `minimal-ui`,
icon: `src/images/gatsby-icon.png`, // This path is relative to the root of the site.
},
},
{
resolve: "gatsby-source-graphql",
options: {
// Arbitrary name for the remote schema Query type
typeName: "DRUPAL",
// Field under which the remote schema will be accessible. You'll use this in your Gatsby query
fieldName: "drupal",
// Url to query from
url: "https://intl-pgs-rsm-growth-platform.pantheonsite.io/graphql",
},
},
],
}
Here's my gatsby-config.js file
When I run gatsby clean && gatsby develop or just gatsby build i get
success createSchemaCustomization - 0.005s
ERROR #11321 PLUGIN
"gatsby-source-graphql" threw an error while running the sourceNodes lifecycle:
Unexpected token < in JSON at position 0
ServerParseError: Unexpected token < in JSON at position 0
- JSON.parse
- index.js:35
[test-gatsby]/[apollo-link-http-common]/lib/index.js:35:25
- next_tick.js:68 process._tickCallback
internal/process/next_tick.js:68:7
not finished source and transform nodes - 0.506s
My Drupal 8 site is new with the graphql module installed. And the gatsby site is brand new too.
I started getting this issue on Monday after working fine for a while. There were no code changes to my gatsby but all of a sudden I'm no longer able to get drupal data.
There seems to be few examples of using the "gatsby-source-graphql" plugin so if anyone can help please do
In my case, it was a permissions issue in Drupal. I solved it by going to admin → people → permissions and setting all permissions related to GraphQL for the anonymous user.
The Drupal Graph QL Module requires authentication using tokens. You can use Simple Oauth or JWT. I used Simple Oauth and resolved my issue using the following steps:
Install the Simple Oauth module using composer so it installs it's dependancies $ composer require drupal/simple_oauth, then enable the module.
Create a user role for your third party app and assign content viewing permissions for that role
In admin/config/people/simple_oauth add a token expiration time, generate keys using the button provided (make sure they are generated outside of the drupal web root) and add the path to the public and private key files.
In admin/config/services/consumer add a new consumer (or use the default consumer)
Add a secret password in the Secret field and select the new role you created under Scopes, then save the config page.
Make a post request to your site https://intl-pgs-rsm-growth-platform.pantheonsite.io/oauth/token using curl or postman to generate a token using the following body fields:
grant_type: password
client_id: The client id generated `admin/config/services/consumer`
client_secret: The secret you entered in step 4
username: A user in your drupal site that has the role you created
password: The password assigned to that account
The post request should return the access token if successful. Add your token to your app's .env.development file and update your gatsby-config.js file with the Authorization header: (More info about setting up environment variables in your gatsby app can be found here)
{
resolve: "gatsby-source-graphql",
options: {
typeName: "DRUPAL",
fieldName: "drupal",
url: "https://intl-pgs-rsm-growth-platform.pantheonsite.io/graphql",
headers: {
"Authorization": `Bearer ${process.env.GATSBY_API_TOKEN}`
},
},
},
Video Tutorials of the Simple Oauth set up steps can be found here
More information on this set up process can be found here
I have the next problem with Sonata Media:
I'm trying to use the Rackspace CDN for uploading images:
My config file looks like this based on current documentation:
cdn:
server:
path: %cdn_url%
filesystem:
local:
directory: %kernel.root_dir%/../web/uploads/media
create: false
rackspace:
url: %rackspace.opencloud.host%
secret:
username: %rackspace.opencloud.username%
apiKey: %rackspace.opencloud.api_key%
region: LON
containerName: projectName
create_container: false
replicate:
master: sonata.media.adapter.filesystem.opencloud
slave: sonata.media.adapter.filesystem.local
And on providers config:
providers:
image:
filesystem: sonata.media.filesystem.replicate
cdn: sonata.media.cdn.server
resizer: sonata.media.resizer.square
allowed_extensions: ['jpg', 'png', 'gif', 'jpeg']
allowed_mime_types: ['image/pjpeg','image/jpeg','image/png','image/x-png', 'image/gif']
The problem is(how I discovered this bug)if Rackspace is down or incorrect username/password are provided on every page of the app I'm getting this answer:
Client error response [status code] 401 [reason phrase] Unauthorized [url] https://lon.auth.api.rackspacecloud.com/v2.0/tokens
This is because Gaufrette Opencloud tries to create a connection on Kernel load.
The quickest solution as a temporary fix was to create a compiler pass and check if the authenticate method returns false then replace argument 0 for replicate definition with the local filesystem adaptor.
My questions are:
How can I avoid creating the Rackspace connection on Kernel Load?
In case Rackspace is down how can I swap between Rackspace or other adapter(local or other ftp server)
Thank you in advance and please in case there are not sufficient information provided please leave a comment.
Apparently there is a solution for lazy loading implemented in Gaufrette: https://github.com/KnpLabs/KnpGaufretteBundle/issues/72
All I had to do is:
sonata.media.adapter.open_stack:
class: OpenCloud\Rackspace
arguments: [ %rackspace.opencloud.host%, { username: %rackspace.opencloud.username%, apiKey: %rackspace.opencloud.api_key% }]
sonata.media.adapter.object_store_factory:
class: Gaufrette\Adapter\OpenStackCloudFiles\ObjectStoreFactory
arguments: [ #sonata.media.adapter.open_stack, "LON", ""]
sonata.media.adapter.filesystem.lazyopencloud:
class: Gaufrette\Adapter\LazyOpenCloud
arguments: [ #sonata.media.adapter.object_store_factory, %rackspace.opencloud.container_name%]
And change replicate master to sonata.media.adapter.filesystem.lazyopencloud
Hope it helps :)