In my application I set a global variable in application controller,
In my development machine it works fine and variable is referred accross the application.
But in the production server (Apache passenger), when I change the global variable value through the application, it updates the table but, it doesn't reflect in the application. Every time I have to restart the server to get the global variable changed.
Please advise me where to set the global variable, so that I change the value of global variable from my application.
Thanks
The production Apache server will be using multiple processes and each process will have its own version of your application. Setting your global variable in one process won't affect the variable's value in any of the other processes.
If you need to share some information across instances, you'll have to store it in a database or similar common data store that is shared by all your server processes.
Related
i am trying to make two http requests with different timeouts per flow, i know i can configure globally httpRequestTimeout in the settings.js file but it sets the timeouts for all the flows.
I have two flows running in the same node-red and i need to set different timeouts for different http requests, i couldn't find a way to achieve it. I tried set the msg.req.timeout and msg.req.socket.server.timeout with no sucess.
Is there any way to acess the variables that are defined on settings.js? Mapping it to a env variable would be good as well.
Unfortunately this can only be set globally in settings.js and not over-ridden on a node by node basis.
You can set variables in settings.js from environment variables since the file is effectively executed at startup so.
...
httpRequestTimeout: process.env.HTTPREQUESTTIMEOUT,
...
This would set the timeout to the value of the HTTPREQUESTTIMEOUT environment variable.
I use Heroku to deploy a Rails app. I store sensitive data such as API keys and passwords in Heroku's environment variables, and then use the data in rake tasks that utilize various APIs.
I am just wondering how secure Heroku's environmental variables are? Is there a way to hash these variables while retaining the ability to use them in the background somehow?
I came across a previous thread here: Is it secure to store passwords as environment variables (rather than as plain text) in config files?.
But it doesn't quite cover instances when I still need to unhashed password to perform important background tasks.
Several things (mostly my opinion):
--
1. API Key != Password
When you talk about API Keys, you're talking about a public token which is generally already very secure. The nature of API's nowadays is they need some sort of prior authentication (either at app or user level) to create a more robust level of security.
I would firstly ensure what type of data you're storing in the ENV variables. If it's pure passwords (for email etc), perhaps consider migrating your setup to one of the cloud providers (SendGrid / Mandrill etc), allowing you to use only API keys
The beauty of API keys is they can be changed whilst not affecting the base account, as well as limiting interactivity to the constrains of the API. Passwords affect the base account
--
2. ENV Vars are OS-level
They are part of the operating environment in which a process runs.
For example, a running process can query the value of the TEMP
environment variable to discover a suitable location to store
temporary files, or the HOME or USERPROFILE variable to find the
directory structure owned by the user running the process.
You must remember Environment Variables basically mean you store the data in the environment you're operating. The generally means the "OS", but can be the virtual instance of an OS too, if required.
The bottom line is your ENV vars are present in the core of your server. The same way as text files would be sitting in a directory on the hard drive - Environment Variables reside in the core of the OS
Unless you received a hack to the server itself, it would be very difficult to get the ENV variable data pro-grammatically, at least in my experience.
What are you looking for? Security against who or what?
Every piece of information store in a config file or the ENV is readable to everyone who has access to the server. And even more important, every gem can read the information and send it somewhere.
You can not encrypt the information, because then you need to store the key to decrypt somewhere. Same problem.
IMO both – environment variables and config files – are secure as long you can trust everyone that has access to your servers and you carefully reviewed the source code of all libraries and gems you have bundled with your app.
I have created a MVC application and tested in my local , it was working as expected, but when I deployed in to an other server in application pool. It is not retaining the Application State Variable value.
So I changed all the Application State variable to Static custom objects and tried.Again I cannot get any values from the static variables used.
As I seen from some blog,I changed the mode from Integrated to Classic, even then I can get the value.
Can any one please help me in getting out from the issue
Are you deploying to a webfarm or are your servers clustered? if so - thats the problem. There is no guarentee you will hit the next server the same one as the one that served the request. The app pool has nothing to do with the behavior here (only in exceptional scenarios) but rather your environment.
Did you create a seperate app pool for this application? if not - its best practice to do so.
I have my Apache web server fronting a Rails application. When a request comes in one of the Apache modules looks at the request and puts information into an Apache environment variable. My question is, is there a chance that one request can overwrite the environment variable of another request and have things get mixed up in the Rails layer?
Are Apache Environment Variables shared across Apache processes?
It sounds like you're using mod_setenvif, in which case, according to Environment Variables in Apache:
For additional flexibility, the directives provided by mod_setenvif allow environment variables to be set on a per-request basis, conditional on characteristics of particular requests.
It makes no sense to me that variables set in one request could affect another request. Race conditions would be rampant and nothing would work.
I'd like to know why is there a need to restart the server (Mongrel/WEBrick) every time a model file is updated? I know it doesn't get loaded in if you don't do it - but is there any documentation out there that would explain why it does so?
Thanks!
Development environments do not require you to restart the server if you change a model. They will reload the environment for each request if necessary.
Production environments are a different story. A Rails server (mongrel/passenger/webrick/etc) running in a production environment will only load your Rails environment once when the process is started. This takes a couple of seconds, as you might notice when starting the console which also loads your Rails environment. To avoid this overhead for each request the server will spawn a new thread from the loaded environment to handle each incoming request.
Because the server only responds to HTTP requests, and the usual signals. There's no good way to force an environment reload beyond always loading a fresh environment (like a development environment, or restarting the server.