I want to use mongolab from client js. I aware that reading data from db will be accessible for anyone who knows my API key. But I must to forbid modifying of database. I can't search for actual information. Only old posts, that could be already outdated (I hope guys from mongolab improving their product). I think that it may be possible because we have different API keys for each account user.
So, is it possible at current time to set read only access for account user?
Related
I am using keycloak on one of my projects. On the backend I am using sringboot and calling Keycloak REST API.
I would love to have info about roles (better would be client's roles, but realm roles will be sufficient) of each users, when fetching it's profile.
URL where I am trying to fetch user: <host>/admin/realms/<realm>/users/<id>
At this moment, I have to programmatically loop over each user and fetch his roles. Which means many and many additional requests. Imagine having 500 users... And yes, I know I could paginate them etc.
I have been trying to find something on the internet for sooo long time, but nothing works. I am able to add them to the access token, but I can't add them to the user info.
If there is anyone who knows how to enrich user info, just point me the right directions. I have been messing with client scopes for so long and I still don't understand them at all. I could not even find a good tutorial on this topic..
You should develop your own KeyCloak extension:
https://www.keycloak.org/docs/latest/server_development/#_extensions_rest
You need java and nhibernate skills.
I have a client-side react app that I need to fetch information from a MongoDB Atlas collection that is being populated directly to the source by another individual. When I went to check out the connection string I noticed that the user password for db access would need to be present in the code:
(Not enough rep to post images sorry)
https://i.imgur.com/5Vs23WJ.png
Now obviously if I include this right in my front-end code anybody will be able to see my password and that's no good. But I need this app to be self-contained and I don't want to have to host a server just to reroute the single Get request that is called upon loading the site.
If I create a new user with read-only privileges, is it safe to keep that user's (super generic obviously) password in the front-end code for access to the db? Is there any harm in this? Am I correct in assuming that non-whitelisted IP addresses aren't able to make requests to the Atlas db? The only address that is going to be whitelisted is the IP where the web-app will be hosted, so I'd imagine I don't need to worry about someone spamming requests to rack up charges on my Atlas account or doing anything else malicious?
I'm a recent grad so I don't have much experience with secure deployment but I'm hoping I can change that this summer.
Thanks :)
I'm not sure about "best" practices, but I'll try to answer according to what I would do:
is it safe to keep that user's (super generic obviously) password in the front-end code for access to the db?
Yes you can create a read-only user. It's generally not a good idea to use a super-user to do your reads. I would only give as much access as the job requires.
Am I correct in assuming that non-whitelisted IP addresses aren't able to make requests to the Atlas db?
Correct. Only whitelisted IPs will be able to connect to the Atlas instance.
Having answered that, I personally would either:
create an API layer on top of the database to prevent direct access to the database by a client application, or
(If applicable) create a Stitch Webhook that provides a Stitch-based REST API layer on top of the Atlas deployment.
The idea is to provide security by limiting access to the database from the outside world. Using a whitelist is one layer of security. Using a REST API is further security layer that essentially forces anything that needs database access to go through a guarded gate that is under your control.
Some additional benefits of a REST API gateway:
Should your Atlas URI changes in the future, you don't need to redeploy the client applications everywhere again. You just reconfigure the REST API gateway to point to the new Atlas URI, while your client application can still use the existing REST API address with no change.
Limiting client connections to the database itself. Since only your API gateway can connect directly to the database, there is little chance that the database can get accidentally DDOSed when you have a lot of clients active at the same time.
Note that I would not consider the above to be "best" practice by any means. It's just how I would do it.
I want to create an app with IONIC to manage buildings. A user can hold multiple buildings. Each building has rooms. Each rooms has logs. Each user is a member of a cooperation.
For many years I've used LAMP. Now moving to mobile and made some IONIC apps. With 2 apps I've used sqlLite as datastore on the mobile device.
But now I've read up on couchDB and pouchDB and really like the concept and the sync option. So now I'm looking into this to use as my datastore (on the mobile and also on the backend).
Now I've got 2 major questions/concerns:
1) Authentication
In my LAMP situation, I usually have an SESSION (table which holds the sessions strings and userID) and an USERS table.
When the user logs in, the user is lookup in the USERS table, and a session string is created and saved with the userID.
Now each time a request is made to the server (for example update data), the session string is also supplied and matched to the SESSION table and retrieve the correct user. From that point on, I can validate if the post is valid and the data also belongs to the correct user.
Back to couchDB, I know there is a cookie management in couchDB (http://guide.couchdb.org/editions/1/en/security.html).
So here I can validate if an user exists and validate the credentials. Now the app can send requests with a cookie.
2) Fetch/Update the right data
In my LAMP situation, I always knew which data belongs to which user. And the back end always checks if this is correct.
In my couchDB I want to create database and each document is an user with all the data.
So now here comes the problem. I can validate an user in couchDB, put there's no way to validate the data (at least as far I know of) that it belongs to the right user.
My goal is that the mobile device syncs the document to the couchDB server.
3) Database structure
At first I wanted to create a database per user. But this is not scalable. Also an user is an member of a cooperation. I also need to generate reports per cooperation/user.
So now I was thinking to create a database per cooperation. But now the problem is, when a user login, I need to know wich database to connect to lookup the user data.
Now I want to use 1 database and each document is an user and holds al data (buildings/logs).
Has anybody got some other suggestions/resources on this approach?
You can try couchdb in combination with superlogin:
SuperLogin is a full-featured NodeJS/Express user authentication solution for APIs and Single Page Apps (SPA) using CouchDB or Cloudant.
github
Tutorial
i know this is a question that has been asked many time. but im still concerned about best practice when trying to develop secure code in meteor.
i know you can prevent the client from being able to access the database with the command:
meteor remove insecure
my code currently adds, retrieves records by using Meteor.methods() so although the client is not able to insert data into a collection, it can use the Meteor.method() function. im concerned about holding the login details in the database because would this not mean that the client can use the Meteor.method() function to add/get/remove data from the database.
the client being able to call the Meteor.methods() function seems to still keep the same risk doesn't it? or have i coded me work wrong?
if it help, here is a run down of what my work is doing:
application loads
client calls to get username and password from database
client sends login details to external server (over https) to initiate socket.io connection.
step 2 is the risk because it seems to allow the client to get the login details. once it has this, it uses the socket.io.js library and the api to my webservice to login. so meteor remove insecure doesnt seem to have secured it because get methods are still available in the Meteor.methods()?
being able to use these functions are quite crucial to retrieving data from the database, is there a way around this? what would be best practice for communicating to the database without exposing private data to the client?
Meteor's insecure package is just a tool provided by MDG to quickly prototype apps. It is not meant to be runned in a production app and some people think is a best practise to remove it all together from the start.
After you remove this package, if you want to interact with the database on the client using mini-mongo you must create the appropiate allow and deny rules on the collection. Here is the link for the Meteor documentation on this topic. The other way to interact with the database, is as you said, using Meteor.methods().
Meteor methods calls don't trigger allow or deny rules, since they are runned on the server. You must hardwire all the security measures you need on the Meteor Call by yourself. So it can be a security problem if you don't take the time to secure the call.
Regarding authenticating your clients I would suggest you take a look at Meteor's Accounts package. For example you can add this two packages for basic username/password authentication:
meteor add accounts-base accounts-passwords
Then you can just use the methods detailed on the Meteor Documentation.
I hope this helps.
Login
If you are using accounts-password, you can check the source here to see details of how it works. But here's a rough overview of it. When you call Meteor.loginWithPassword, the password is hashed client-side. Then a method is called with the parameters. The password is then salted and checked against the database server-side. If it matches, the client gets logged in. The client then subscribes to their own user data (Meteor.user()). The server only publishes their data. So everyone else's data is save.
Methods
A method executes code server-side. So they are generally secure. But you can of course write insecure methods. Just know, that you can't trust the parameters passed by the user.
In MongoLab you generate an API key and then anyone can access your database using REST API.
Usual case is to use the REST api directly from Ajax clients.
But this gives anyone complete write access to your database, which is security hole.
Is there a way to generate an API key which will give READ ONLY access to the database
Currently, all API keys have read and write access to the databases associated with the user's account. If you need to expose a read-only API we recommend building your own with one of the many frameworks available like Express or Sinatra.