Closed ameensol closed 10 years ago
You should be able to leverage heroku's environment variables by doing something like this:
var nconf = require('nconf');
nconf.file('./config.json')
.env();
nconf.load();
Right now you are leaking your password to the world in the config.json in a public repo. This way you can use the config.json when doing local development but have a different value when the site is in production.
Sure, using Heroku's environmental variables for a static password could work.
However, not leaking the password to the world is as simple as adding the config.json to the .gitignore file. I left that out for the moment so it could be tested right out of the box using the "brigade" password. All he'll have to manually configure is changing the password to whatever he wants, adding the file to the .gitignore, and then removing the file.
I was under the impression environment variables were the current best practice to secure sensitive data for your heroku app?
It looks like my auth implementation diffs got overrun somehow, so I'll go ahead and explain what I changed and how it should all work.
1) public/views/projects.html Prompt the user with a password input, which is submitted once a user clicks the button. Show the password input while 'authSucces' is false, which is the initial condition, and show the projects list once 'authSuccess' is true.
2) public/js/controllers/projects.js When the user submits the password, an $http POST request is made to the /projects/auth Express endpoint with the password as the data. If an error is received, the password is reset and an error message is displayed on the view. If no error is received, then the 'authSuccess' variable is set to true.
3) config/routes.js I added a new route for /projects/auth, which executes the projects.auth function.
4) app/controllers/projects.js I added the export function projects.auth. We can use nconf to grab the password from the config.json file (which should be added to the .gitignore) or conform to best practices as @akilism suggested and use Heroku environmental variables - it really doesn't matter. Either way, if the password receives matches the stored password, the response will be a truthy res.jsonp(1). Otherwise, the response will be a 403 (forbidden) error.
The primary factors I considered for this implementation were avoiding the creation of full user accounts, and making sure that authentication happened on the server side. Sending an $http POST to verify a static password meets those criteria. The most important vulnerability at this point is sending the password as POST data un-encrypted.
Sorry for unresponsiveness on this one, I'll try to get some of these things pulled in tonight at the meetup.
-C
Looks like the projects page is down. I think something in this commit isn't playing well with heroku.
Thanks, I had to rush out and didnt get a chance to test it. I'll roll back to the last commit. On Jan 22, 2014 10:27 PM, "Gunnar Aasen" notifications@github.com wrote:
Looks like the projects page is down. I think something in this commit isn't playing well with heroku.
— Reply to this email directly or view it on GitHubhttps://github.com/chriswhong/betanyc-projects-list/pull/11#issuecomment-33094127 .
Sorry about this.
Did you install all the dependencies (including step and dotenv) on Heroku? My commit removed the node_modules and added it to .gitignore, so Heroku might not be getting it.
Otherwise it could be something with the environmental variables.
I added a .gitignore file and removed the node_modules directory. The dependencies can be installed for this module using npm, and all future dependencies will be ignored by git.