I've been trying to implement authentication and session management in a node.js application using socket.io.
And from almost all the resources I found, I came across the term "session store".
There are open source tools that handles sessions for us, but we have to provide them with a session store.
Some tools has built in storage for sessions in memory, for example the module express-session comes with a default in memory session store, but also this warning:
Warning The default server-side session storage, MemoryStore, is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.
So I searched for the available stable session stores and it turns out that most of the names are databases that I've heard of.
For example, here's a list of session stores and another one at GitHub that I've came across.
The names include MongoDB, MySQL, SQLite, cassandra, firebase etc, hence the confusion.
So the question is, are session stores and database the same..? (I can think of it like - when we're using the database for storing session details we call it session store but it's in fact a database)
If not, how do they differ..?
Session store is a place where session data is being stored on server.
On web its usually being identified by a cookie stored in clients browser.
So it allows your app to identify user and keep him logged in for example.
Session can either be memory, some database, simple files, or any other place you can come up with to store session data.
If you project uses some database, you can configure your session store to use the same database, to avoid having another database on server just for the purpose of session store.
Differences between different session stores:
Memory session store is going to be reset on every app re-lauch. Also its fastest.
Database session store, is going to be safe with app
re-lauch. And at some point you will have alot of session objects
which you might want to clean up. And same session stored in database can be even accessed from different apps.
Session store is a method of storing information about user as a session with unique identifier. It could be stored in memory or in database. Socket.io can utilize the same session (id) being used in express app by socket-express-session package, if I am not mistaken.
You can then use session information to grant/restrict access, for example.
Related
Every time someone hits an API route I want to store that information in database, connected with req. IP.
Afther I would like to find some association rules based on similar searches.
Should I store some information in cookies or to use local dartabase?
Example on some hotels site:
I want to store info that i got a lot of request for cheap hotels in some specific area.
Thnaks.
Definitely in a database. Cookies wouldn't make sense because
You cannot rely on cookies for persistent data. They can expire, be cleared, etc.
Cookies can hold a very limited amount of data (4093 bytes usually)
Cookies are stored locally on your client's browser, you want information across all of your clients.
Tracking user behavior data is very common web feature. You may want to use a web analytics service such as Google Analytics rather then implement your own.
For my Next Project (web + electron + ionic),
I want to use angularjs but don't want to use nodejs and for database.
I am thinking about pouchdb or google-firebase.
Now security is an issue for my database. like i have to connect with my database using angular because i will not use nodejs.
So i have to put my username and password on connection.
will my username and password secure ?
I am thinking that anyone who press Ctrl+u or from dev tool can see my user access.
Any suggestions ?
try angularfire2 library for firebase using this library no needed nodejs or any backend server. it's directly communicate with firebase.here is library
https://github.com/angular/angularfire2
I am afraid that you can't do that, you need some server side application to connect with the database in a secure way.
There is some gold rules you must always follow:
There is no security from the client side.
Never trust on information that comes from the client, even if you think it's validated.
For the security purpose, you can go with firebase auth
these are many secure login methods like
-FirebaseUI
-Password-Based
-Facebook
-Google.. etc
reference link- https://firebase.google.com/docs/auth/web/start
If you are planning to use firebase for the huge database then one thing keep in mind firebase is not designed for the huge database it's limited.You can't compare firebase to SQL n MySQL etc databases. Firebase specifically designed for small databases.
If you grant write access for your chat clients by one hardcoded credentials (really easily get known) - you are on very dangerous side: one can quickly fill your DB with tons of garbage. There is no harm to hardcode read credentials (in order to separate access to different server DBs, i.e.) but for write ones you definitely need registration, which means Node or something. It will handle new users creation and give you ability to block unwanted client behaviour, just in case.
What is the best design approach in term of security, performance and maintenance for REST API that has many subscribers (companies)?
What is the best approach to use?:
Build a general API and sub APIs for each subscriber (company), when request come we check the request and forward it to the sub API using (API Key) then retrieve data to general API then to client.
Should we make single API and many databases for storing each subscribe(company) data (because each company has huge records that why we suggested to separated databases to improve performance)? when request come we verify it and change database Connection String based on client request.
Should we make one API and one big database that handle all subscribes data?
Do you suggest any new approach to solve this problem? We used Web API and MS SQL Server and Azure Cloud.
In the past I've had one API, the API is secured using OAuth/JWT in the token we have a company id. When a request comes in we read the company id from the JWT and perform a lookup in a master database, this database holds global information such a connection strings for each company. We then create a unit of work that has the company's conneciton string associated with it and any database lookups use that.
This mean that you can start with one master and one node database, when the node database starts getting overloaded you can bring up another one and either add new companies to that or move existing companies to take pressure off. Essentially you're just scaling out when the need arises.
We had no performance issues with this setup.
Depends on the transaction volume and nature of data, you can go for a single database or separate database for each company.
Option 2 would be the best , if you have complex data model
I don't see any advantage of going for option 1, because , anyway general API will call for each request.
You can use the ClientID verification while issuing access tokes.
What I understood from your question is, you want an rest API for multiple consumers(companies). Logically the employees from that company will consume your API, employees may be admin, HR etc. So what I suggested for such scenario you must go with single Rest API for providing the services to your consumers and for security you have to use OpenId on the top of OAuth 2. This resolves the authentication and authorization for you.
We're using Cloudant as the remote database for our app. The database contains documents for each user of the app. When the app launches, we need to query the database for all the documents belonging to a user. What we found is the CDTDatastore API only allows pulling the entire database and storing it inside the app then performing the query in the local copy. The initial pulling to the local datastore takes about 10 seconds and I imagine will take longer when adding more users.
Is there a way I can save only part of the remote database to the local datastore? Or, are we using the wrong service for our app?
You can use a server side replication filter function; you'll need to add information about your filter to the pull replicator. However replication will have a performance hit when using the function.
That being said a common pattern is to use one database per user, however this has other trade offs and it is something you should read up on. There is some information on the one database per user pattern here.
What's the best practice or the common way of keeping (or not keeping) Evernote users in your application's database?
Should I create my own membership system and create a connection to Evernote accounts?
Should I store Evernote user data (or only part of it) in my own app and let the user log in only with Evernote?
Summary: you must protect their data but how you protect it is up to you. Use the integer edam_userId to identify data.
I think the API License agreement covers protection in the terms:
you agree that when using the API you will not, directly or indirectly, take or enable another to take any of the following actions:...
1.8.4 circumvent or modify any Keys or other security mechanism employed by Evernote or the API;
If you cache people's data and your server-based app lacks security to prevent people looking at other's data, then I think you're pretty clearly violating that clause. I think it's quite elegantly written!
Couple that with the responsibility clause 1.2
You are fully responsible for all activities that occur using your Keys, regardless of whether such activities are undertaken by you or a third party.
So if you don't protect someone's cached data and another user is able to get at it, you're explicitly liable.
Having cleared up the question of your obligations to (as you'd expect) protect people's data, the question is how do you store it?
Clause 4.3 covers identifiers pretty directly although it's a bit out of date now that we are all forced to use oAuth - there are no passwords ever entered into anything other a web view. However, mobile or desktop client apps must provide a mechanism for the user to log out, which must completely remove the username and password from your application and its persistent storage.
For a web app, you can't even save the username: If your Application runs as an Internet service on a multi-user server, you must not ask for, view, store or cache the sign-in name or password of Evernote user accounts.
The good news is that you can rely on the edam_userId value which comes back to you in the oAuth token credentials response, as discussed here.
When you look at the Data Model, you can see the unique id under the User and going into the User struct, see the reassuring definition The unique numeric identifier for the account, which will not change for the lifetime of the account.
Thinking about the consequences, as you can't get the user id until you have logged into the service, if you want to provide a local login for people you will have to link your local credentials to the user id. That may irk some people if they have to enter a username twice but can't be helped.
You can allow users to log-in via OAuth. Here's a guide on how that process works.
But you'll probably also want to store a minimal amount of user data, at least a unique identifier, in your database so you can do things like create relationships between the user and their notebooks and tags. Refer to the Evernote data model for those relationships. If you're using rails, this will also help you take advantage of rails conventions.