I'm using Ring(Clojure) on Heroku and I'm implementing some tests in the app. Some of the tests are GET requests to the app, and the app has a PostgreSQL database that fills some pages. But, to do so, the app has to connect to the original Heroku database.
How can I test if some content is present in a GET request without putting the database connection specs (url, user, password) in the .travis.yml file? Am I even supposed to do that? Or should I just setup a test database, fill it with test data and test the contents, with a localhost connection?
Thanks.
I think you could put the credential in a Travis Encryption key. The only problem is that Pull Requests cannot use the decrypted keys (for security purposes).
Related
I am have AWS EC2 Server with my App Backend and Database there.
My new developer needs to upload few things in the Database and update Backend code but I don't want to give him the PEM.
He needs to SSH
Whats the best possible way to do it? I was thinking of creating an IAM User for him - but I only want him to give SSH Access, so permission would that be? I could only find a general full permission EC2 which would also give him permission to edit the Security Group and things like that.
I do trust him well, but I just don't want to give him full access in general.
What can I do?
Why not allow your developer to connect using session manager.
If you use this he can access the environment either in his browser or via the AWS CLI.
He should be able to mimic a regular session but without having the key, then when he's done you remove the permissions of the server. You can also enable logging to check the history of his sessions actions.
If you want to update code you should at some point take a look at using code deploy to have the code automatically rolled out without even accessing the server.
I am interested in barring pgAdmin access to my PostgreSQL server from any station other than the server. Is is possible to do this using pg_hba.conf? The PostgreSQL server should still allow access to the server for my application from other stations.
No, this isn't possible. Nor is it sensible, since the client (mode of access) isn't the issue, but what you do on the connection.
If the user managed to trick your app into running arbitrary SQL via SQL injection or whatever, you'd be back in the same position.
Instead, set your application up to use a restricted user role that:
is not a superuser
does not own the tables it uses
has only the minimum permissions GRANTed to it that it needs
and preferably also add guards such as triggers to preserve data consistency within the DB. This will help mitigate the damage that can be done if someone extracts database credentials from the app and uses them directly via a SQL client.
You can also make it harder for someone with your app's binary etc to extract the credentials and use them to connect to postgres directly by:
using md5 authentication
if you use a single db role shared between all users, either (a) don't do that or (b) store a well-obfuscated copy of the db password somewhere non-obvious in the configuration, preferably encrypted against the user's local credentials
using sslmode=verify-full and a server certificate
embedding a client certificate in your app and requiring that it be presented in order for the connection to be permitted by the server (see client certificates
Really, though, if you can't trust your uses not to be actively malicious and run DELETE FROM customer; etc ... you'll need middleware to guard the SQL connection and apply further limits. Rate-limit access, disallow bulk updates, etc etc.
Is it still possible to deploy to meteor.com and protect it using a password?
When I search for this I find things like
$> mrt deploy -P example.meteor.com
but that doesn't work. I guess something has changed here and I get the impression this feature is removed
Meteor no longer supports deploying with a password directly, and for good reason!.
All publishes are linked to a Meteor developer account. These give:
Ability to allow other users to have access to your apps
Abililty to see all sites you have
Ability to publish without putting in your password every time
(In future) more fine grained permissions options (I'd imagine, considering galaxy's commercial target base).
Simply meteor login, or publish your app like you would normally to kick off the signup process. You can meteor logout to switch to another account.
After you deploy your app, you can see the sites you are authorized with meteor list-sites.
I'm going to deploy a website to Azure using MongoLab, but I got into a bit of confusion.
When I log to MongoLab site I get one Uri, but in the Azure site, if I hit connection string I get a different one. The Azure one is quite long and there is no space for putting user and password.
I get the Azure connection string when I select it in the main management site and hit the Connection Info button below. The other one I see it in the MongoLab site.
Also, I made the MongoLab DB from within the Azure Portal.
The connection string I see in Azure is this
mongodb://AzureAppServiceName:M.qKtufxLrRxv.1SwDBKelfkchdjCe08Cmv79lvTD2I-#ds035747.mongolab.com:port/DBName
And the one in MongoLab site is this:
mongodb://<dbuser>:<dbpassword>#ds035747.mongolab.com:port/DBName
Which one should I use?
I'm wondering that one is for direct connection to MongoLab when there is no restriction of ports whatsoever, such as development, and the other one is to connect when the site is deployed because of internal network restrictions in the Azure infrastructure.
Is this understanding correct?
The connection string provided in the MongoLab UI is a template that can be used when constructing your own URI when you create database users of your own.
When you provision a MongoLab database using the MongoLab addon in the Azure store, MongoLab passes the connection URI we generate to Azure. This pre-generated URI is the one available in the "Connection Info" section of the addon screen.
You can immediately use that URI in the connection info screen as suggested in the Quick Start provided at the top of this article: http://azure.microsoft.com/en-us/documentation/articles/store-mongolab-web-sites-dotnet-store-data-mongodb/. The quick start provides the steps for transferring the addon connection info to the environment variables of an Azure website.
It is also, as other responses suggest, entirely plausible to use that URI elsewhere or to create your own username and password after SSOing to MongoLab (using the URI template at the top of the page to construct a URI of your own).
Don't hesitate to email us at support#mongolab.com directly if you have any questions!
Sincerely,
Eric#MongoLab
You should go with the one provided when you go to the details of your database on the MongoLab site. It should look like this
mongodb://<dbuser>:<dbpassword>#ds048537.mongolab.com:48537/<databasename>
I don't know what kind of connection string Azure is showing you, but the format above works pretty well on Azure.
in my application i uploaded sqlite database on the server.
problem is that i have no knowledge how to access the database from the server in my application.
Please tell me anyone how i access database from the server.
Since SQLite is a flat file database, there's no way to access it via server (because it doesn't have one duhhh).
Best approach would be either by downloading the database into your sandbox and opening it from there. Or create a simple API to manipulate the database via PHP for example.