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.
Related
I have developed a standard Google App Engine backend Application for my Android client. Now, there is search functionality in the App and during one request, I plan to return 20 results but I search for more in advanced(like 100) so that for the next hit, I will just search in these records and return. So, I need a mechanism to save these 80 records so that the same user might get them quickly.
I searched for it and found out that we can enable sessions in appengine-web.xml but all the session access has been done in doPost() and doGet() while my code is entirely Google's cloud endpoints.(like Spring)
Another thing is that I would like to persist the data both inside the Datastore and some cache(like Memcache).
My end goal is storing this data across search sessions. Is there any mechanism that will allow me to do this?
The usual approach here is to provide a code value in the response which the user can send in the next request to "continue" viewing the same results. This is called a "cursor".
For example, you might store the 80 records under some random key in your cache, and then send that random key to the user as part of the response. Then, when the user makes a new request including the key, you just the records and return them.
Cookie-based sessions don't usually work well with APIs; they introduce unnecessary statefulness.
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.
I'm developing a single page booking application using angular which interacts with my REST API.
I have various routes defined in my application and I'm using local storage to store the state of each page as a user fills in their information. Once the user has filled in everything, I post this to my API, generate a hash and redirect them to a payment gateway before coming back to a results page. The reason for local storage is so we can persist a users filled in details, even if they close the page and re-open it.
I shouldn't store sensitive information such as user names and addresses in local storage though, because this leaves me vulnerable to cross site scripting.
Storing this information on the server would break the stateless principles of REST API's.
Are there any suggestions on how to best architect my application?
Edit: the content below is incorrect. Cookies and local storage are both domain restricted. Local storage's main weakness is that it can be accessed and modified by local users and programs indiscriminately, and that treating the contents of local storage as trusted input opens the door to nasty DOM XSS and stored XSS attacks.
One option would be to use cookies to store the user's information. You could have a cookie per field, set the cookie when the user fills in the field, and read the cookies to populate the fields when the user loads the page.
I have an angularjs app that is on a separate domain than my backend, and the users from my backend all have roles and permissions that allow them access to various areas and elements of my frontend.
Before, I was just storing to a cookie and checking as I needed through the use of angular services and whatnot, cool.
Now the permissions datum have reached the point where they are too big to store in a cookie in the browser. And I'm avoiding Localstorage for fear of user tampering.
The Question:
How do I store the users sensitive data (or anything sensitive, really) that are too big for cookies on the client side in a manner that is safe and doesn't require API calls all the time to get?
I don't want to have to phone home every page change to get this data direct from the server when I need it, because I feel this would be really detrimental to the speed and flow of the site, not to mention the frequency at which this would need to happen would be ridiculous for my app.
Keep in mind that I do proper permission checking on the backend before carrying out any actions, but I'm more concerned about users tampering with their permissions to show certain elements that were removed on the frontside before.
What would be your solution or your advice on this?
If it ends up on the user's computer, regardless of whether it's in a cookie, in local storage, in the URL, in the browser's cache, or anywhere else on the user's computer, assume that the user can see it and mess with it. (You could encrypt it, but if your client-side logic knows how to decrypt it, you're back to step one.)
The best that you can do is exactly what you've described - be sure that the server only carries out authorized actions, and never trusts what the user tells it.
I have an application deployed on GAE. It allows users to register for an account, and I use the google user id as the primary key to link to their account.
I have a registration link that should be visible if either the user has not been authenticated by google and/or they do not have an account on my site.
What I am trying to figure out is what is the best way to figure out if the user has an account on my site as they go from page to page. I have an authentication filter that is triggered on every page, and the filter looks at their google id (if they are logged in), goes off and determines if the user has an account on my site, and sets a request parameter, that I use in the jsp to determine whether or not to show the registration link.
It seems wasteful to do that every time, so I refactored it and had the authentication filter store the Key object tied to their user account on my site in a Session. If the key attribute is not null, I take that to mean that the user is registered on my site.
Does that seem logical, or are there better approaches? The complexity to me comes from the fact that the user may be logged in with google, but that doesn't necessarily mean they have an account on my site.
My question
When it comes to storing authentication data, you have two options :
Store the data in session
Store the data on client side, in a cookie typically
Storing the data in session is a perfectly valid mechanism, and that's actually the most common.
However, managing a session is costly (you need to store it). In App Engine's case the sessions are stored in the Datastore, with probably some caching. So it's still a call to the datastore.
That should be totally acceptable, however if it turns out managing a session really decreases you app's performance, you can always store the data in an encrypted cookie. That way the information is provided by the browser every time it sends an HTTP request. Note that it means you must get encryption right and that HTTP requests will be slightly bigger (the size of the encrypted data).
So in the end it's a tradeoff. I would recommend sticking to sessions unless you experience performance issues. The advantage of sessions (compared to your fist approach) is that if you ever want to store additional data, you will have less code to add.