- the dal URI if it contains logins/password/db that is not localhost - eventually janrain key is to be kept private as well. PS: Auth.settings_hmac_key in modern scaffolding apps is not written "plainly": it is replaced by Auth.get_or_create_key() that reads from private/auth.key or it creates a new one (so if you don't ship private/auth.key you're fine)
My "normal" environment is having a 0_production.py and a 0_test.py with DAL URI, db connection, Auth and mail parameters. In the db.py reside all define_table() statements. Publishing 0_test.py to the repo, added 0_production.py instead to the ignore list. When deploying to production server, 0_production.py is already there (or transferred separately), 0_test.py is renamed to 0_test.py.bak. Little trick, you can have a 0_Atest.py and a 0_Zproduction.py . As long as all the things defined into 0_Atest.py are "redefined" into 0_Zproduction.py you are fine (models are executed alphabetically). Anyway it's not recommended, also for performance issues (ideally you have already a "deployment" script and renaming one file shouldn't be so hard ^_^) On Tuesday, September 11, 2012 9:20:34 PM UTC+2, monotasker wrote: > > I'm using github for open-source development of some web2py apps and want > to make sure I'm not exposing any data that would be a security risk. As > far as I can tell, the sensitive pieces of data in a standard app would be: > > - email account information (by default in db.py) > - any recaptcha keys (by default in db.py) > - the private/auth.key file > > What about the Auth.settings.hmac_key that appears in my db.py? (As you > can tell, I'm not familiar with much of how these encryption schemes work.) > Anything else that I'm missing? My plan is to have db.py read any sensitive > data from a text file on the server, in a folder that isn't shared on > github. > > Ian > --
