I'm constantly tinkering with my app and pushing updates live. Unfortunately, I often forget that I've stopped mailgun process.env.MAIL_URL while making changes to the app in the local devlopment environment, so when I push the update live I also stop emails from sending in the production environment. Is there a way to move the process.env.MAIL_URL to a settings-prod.js or something, so I stop making this mistake. I currently have a settings-prod.js and a settings-dev.js for public and private settings, but I think this is for keys.
Curent method
Path: server/server.js
Meteor.startup(function(options, user) {
//load email server - to send email
process.env.MAIL_URL = "mailgun en";
});
This is the exact use case for environment settings, in particular what you should automatically have set to process.env instead of setting it yourself at Meteor.startup.
See:
https://guide.meteor.com/deployment.html#environment
https://themeteorchef.com/snippets/making-use-of-settings-json/
Typically you have 2 different setting files (1 for your dev, 1 for your prod), possibly with different Mailgun links, or you could more simply use a flag (e.g. "sendEmails" = false or read "NODE_ENV" property). Just be aware that some hosting services convert all values to string (hence "sendEmails" = false becomes "sendEmails" = "false" and is truthy...).
Related
Is it safe to use hard coded passwords inside Cloudflare worker code?
Is there a risk that hacker/end user could somehow get access to this pwd or myUrl secret url?
async function handleRequest(request) {
const init = {
headers: {
"pwd": "xyz123"}
const response = await fetch(myURL, init);
You should use secret environment variables for this: https://developers.cloudflare.com/workers/platform/environment-variables/
Cloudflare will not reveal your code to third parties, so hard-coded secrets are not necessarily a problem. However, using secret environment variables will add extra protections, such as making sure that if an attacker were to compromise your Cloudflare account (e.g. if they guessed your password), they cannot easily download the secret through the API (whereas they could easily download your worker code). Additionally, certain Cloudflare employees who work on Cloudflare Workers may be able to view your code if needed to debug a problem in the system, but no Cloudflare employee is permitted to look at your secret environment variables.
I need to write a python script for GitLab that allows me to change the email addresses of users
The problem is that I manage to change various user attributes, such as "bio" and etc
But I can't change the "email".
The script reports a successful change of these attributes, but in fact they do not change.
I am working as the root user, using his token
To change the user attributes, I use this construction
gl = gitlab.Gitlab(arg.url, private_token=arg.token)
user = gl.users.list(username = 'name')[0]
user.bio = f"{user.username}#EXAMPLE.COM"
user.save()
I also tried working with classic requests, instead of the gitlab library, but the result was the same
We are working adding Auth0 to our Next.js website and referencing this example.
What I am wondering about is the settings in next.config.js in the example. It puts the Auth0 and other secrets in the client (via Webpack). Doesn't this put these secrets at risk? Since they are somewhere in the client code, there is a chance that a request can be made to access the secrets.
Examples in this Auth0 article also puts the secrets in the client.
I haven't had much luck finding out how Webpack handles the variables and am looking to the community to shed some light on this. We are trying to ensure our pattern is safe before putting it in to place.
From example, secrets being added to client side next.config.js:
const dotenv = require('dotenv')
dotenv.config()
module.exports = {
env: {
AUTH0_DOMAIN: process.env.AUTH0_DOMAIN,
AUTH0_CLIENT_ID: process.env.AUTH0_CLIENT_ID,
AUTH0_CLIENT_SECRET: process.env.AUTH0_CLIENT_SECRET,
AUTH0_SCOPE: 'openid profile',
REDIRECT_URI:
process.env.REDIRECT_URI || 'http://localhost:3000/api/callback',
POST_LOGOUT_REDIRECT_URI:
process.env.POST_LOGOUT_REDIRECT_URI || 'http://localhost:3000/',
SESSION_COOKIE_SECRET: process.env.SESSION_COOKIE_SECRET,
SESSION_COOKIE_LIFETIME: 7200, // 2 hours
},
}
Update - Next v9.4:
Since Next.js v9.4, it exposes only env variables with the prefix NEXT_PUBLIC_ to the browser.
For more info, read this
Original answer:
DON'T put any secret env variables in a place that is accessible to the client.
I'm not sure what next does with this env property, It just configures a webpack DefinePlugin that replaces usages of process.env.VAR to it's value.
So, this means that your secrets will be inside bundles that are public.
To confirm that it is exposed in the client,
open dev-tools
open console by
pressing esc
click on the search tab
enter your secret key
It will find it in one of the bundles.
I would like to request an API which only allow IP from Hong Kong, therefore I perform a check using https://ifconfig.co/country-iso. Even I set functions.region('asia-east2') as stated in the document page (https://firebase.google.com/docs/functions/locations), the console logged the location detected is US
exports.locationFunction = functions.region('asia-east2').pubsub.schedule('every 1 minutes').onRun((context) => {
request('https://ifconfig.co/country-iso', function (error, response, body) {
console.log("RESULTbody:" + body)
});
return admin.database().ref("mylocation").set("detection finished");
});
If you are using scheduled functions, as you are, then you have an App Engine machine that is required for Cloud Scheduler to work. I think that the default project region might be set to something else than 'asia-east2' that you want.
If the function is set correctly to asia-east2 the only other regional config that can affect is the default project region where the App Engine machine spins up, I think that might be your issue.
Here you have more information on scheduled functions and the information I mentioned about the App Engine machine.
And here you can see more information about default project location.
Let me know.
I have backend meteor server which serves and shares common collections across multiple apps (just sharing mongo db is not enough, realtime updates are needed).
BACKEND
/ \
APP1 APP2
| |
CLIENT CLIENT
I have server-to-server DDP connections running between backend server and app servers.
Atm i'm just re-publishing the collections in app server after subscribing them from backend server.
It all seems working quite well. The only problem tho is that in app server cant query any collections in server side, all the find() responses are empty, in client side (browser) it all works fine tho.
Is it just a coincidence that it works at all or what do you suggest how i should set it up.
Thanks
I realize that this is a pretty old question, but I thought I would share my solution. I had a similar problem as I have two applications (App1 and App2) that will be sharing data with a third application (App3).
I couldn't figure out why the server-side of my App1 could not see the shared collections in App3...even though the client-side of App1 was seeing them. Then it hit me that the server-side of my App1 was acting like a "client" of App3, so needed to subscribe to the publication, too.
I moved my DDP.connection.subscribe() call outside the client folder of App1, so that it would be shared between the client and server of App1. Then, I used a Meteor.setInterval() call to wait for the subscription to be ready on the server side in order to use it. That seemed to do the trick.
Here's a quick example:
in lib/common.js:
Meteor.myRemoteConnection = DDP.connect(url_to_App3);
SharedWidgets = new Meteor.Collection('widgets', Meteor.myRemoteConnection);
Meteor.sharedWidgetsSubscription = Meteor.myRemoteConnection.subscribe('allWidgets');
in server/fixtures.js:
Meteor.startup(function() {
// check once every second to see if the subscription is ready
var subIsReadyInterval = Meteor.setInterval(function () {
if ( Meteor.sharedWidgetsSubscription.ready() ) {
// SharedWidgets should be available now...
console.log('widget count:' + SharedWidgets.find().count);
// clean up the interval...
Meteor.clearInterval(subIsReadyInterval);
}
}, 1000);
});
If there is a better way to set this up, I'd love to know.
I have done this already,
check my app Tapmate or youtap.meteor.com on android and iphone,
I know it will work till 0.6.4 meteor version,
haven't checked if that works on above version,
You have to manually override the default ddp url while connecting,
i.e. go to live-data package in .meteor/packages/live-data/stream_client_socket.js
overwrite this - Meteor._DdpClientStream = function (url) {
url = "ddp+sockjs://ddp--**-youtap.meteor.com/sockjs";
now you won't see things happening locally but it will point to meteor server
also disable reload js from reloading
Thanks