Progressing along with my isomorphic javascript crusade, I put Meteor on a hold while I played a bit more with the MEAN stack. To ward off any further procastination, I've decided to finish my original prototype community application. Now, my biggest issue with Meteor isn't reactivity, it's session/common data.
I know Meteor's native session system is based off of the reactive concept, and cookies don't "exist" because Meteor operates on "the wire". Though let's say I were building an application on the LAMP or mean STACK, and I was creating a user interface. I'd use cookies/sessions to control user activity. If Meteor operates off of reactivity, how do I maintain persistence?
I have searched through atmosphere for packages that fit my criteria, and I ran into a couple of packages that store "presistent sessions". Though these interfaces operate off of the client, not the server; hence my code would be exposed client, therefor setting the application up for exploitaton.
All that being stated, I know Meteor has it's standard user interface. What I'm trying to do here is understand Meteor, and gain experience for future endevours.
Meteor has a built-in login system that keeps track of the logged-in user, which is one of the main reasons people use cookies. If you want to store other data on the client in a persistent way, you can use the HTML5 localStorage API.
I think what you're referring to is that something like PHP lets you store data in a "SESSION" variable that is actually stored on the server, but persisted between different requests from the same client.
If this is what you are looking for, there are several approaches that will give you similar functionality:
Store data associated with a particular user, and use the userId that Meteor gives you to only publish it for that user (using Meteor.publish)
Have a randomly generated client ID that is stored in localStorage, and pass that in when calling subscriptions or methods to authenticate as that client. This will work in the case where the user is not logged in, and will give you a very similar result to cookies/session in PHP. You will still store the actual data in the database on the server, but you will know which data is associated with a particular client by the unique ID.
It's true that Meteor's Session variable is named in a way that can be confusing if you are coming from PHP where SESSION means something totally different.
Does this answer your question?
Related
Beginner question: I built a simple draggable to-do list that caches the state in a single object (tasks, containers and index) - currently, it's storing it in local storage. I am working on the server side using express and node.js, but I am confused as to where I would simply store the object. Would a database like mongodb be a good choice...or is there an even simpler option? I assume I can keep the project static and have the server side just receive and serve up JSON? Thanks!
If you plan to integrate it with backend server, it is actually a good idea to store the object in a database. The benefit is, you can still maintain the state of your to-do-list no matter on which machine you are logging in. If you access your to-do-list app from the browser of your smartphone or desktop, they both still point to a single source of truth, which is your database. Think of it as a Trello board that is in-sync on every device. In your database, you may record the task status, task ID, description, etc. If you want to go further, you can group this information per user, so every user will have their own to-do-list. (which is not possible if you rely on conventional local storage). With database, you can extend the functionality beyond simple to-do-list. Alternatively, you may consider a much simpler solution by recording the object as JSON file and storing it in your server. This solution is feasible albeit limited flexibility.
I would recommend MongoDB Atlas and Firebase Realtime Database as both are beginner friendly and easy to use. Both are free-of-charge on limited usage and hosted in the cloud.
I searched other answers, but couldn't find a compatible solution.
We have an application built in vue which allows unregistered users to upload files within a limit.
For registered users we use JWT with a refresh and access token stored in a http only cookie.
I am looking for guides on best practice to handle anonymous users. Ideally I would like to
a) create a record in the database with a uuid with a role of 'anon'
b) store this uuid client side for the lifetime of this anonymous user i think local storage is sufficient so i can access it on the client.
c) provide a seamless upgrade to a registered user using the same uuid, so all the past interactions are recorded.
I do know that client side storage can be deleted, this is fine, in this case i will create a new uuid.
Do i have the right approach here using the technology stack i mentioned (Vue, JS, Node JS, MongoDB, JWT)
Suggestions of improving these methods are welcome.
Thanks.
Depends on use case, if your application requires the anonymous user to be upgraded to a normal user when he register then you may want to keep a record in DB, but you cannot handle the case when user deletes the local data; then you just need to start a fresh with this user is OK.
But you may want to consider some users might not be comfortable knowing that when they register you already have previous records due to privacy reasons when using app anonymously
I have struggled to find many resources on this online. I am developing an application that multiple users will be using at the same time. This means that one user may edit the database after another user has loaded the data from database. This means that this second user will not have an up to date view of the current state of the database. What is the best way to subscribe to database changes and deal with them. I am using a MEAN stack.
If you are trying to develop a real time system where changes are reflected instantly upon changes in database, you need to make use of web sockets. Since you are using Node.js as backend, see Socket.io
A good resource for implementation can be found here
However, if you plan on implementing web sockets, you will have to make significant changes to both your Node.js and Angular code.
Another method (which I would not recommend) is to make periodic api calls for those views which you want to reflect real time changes. You can make use of setInterval for this
I am developing a simple login system, and I'll have to store two cookies. One indicating which user is logged, and other indicating the "plan" (database) that the user belongs. Well, at client side the first cookie (us_auth) and the second (pl_auth), will store hashes (md5) to make a key that I can check on server side.
Now at the server side I'll store these two keys to assign to them values to route the user correctly. A simple authentication system.
Well, here the question comes. At PHP we have $_SESSION, and at Node we have modules that make the same thing, but I want something that I have more control, to work directly with the data. I have two choices:
Memcached, or a simple global var that store an object with key->value (in my case, hash->value).
What's the best choice in my case? At simple point of view, the second alternative seems to be more fast, pratical and simple.
A simple global variable will fail if you replicate your application. Variables are not shared between processes (or even machines).
If you don’t plan on replicating your app, just restart your process, the memory allocated to that process will be lost, so will your in-memory session variables.
A memcached server can help you with that.
This is not specific to nodejs. You’ll have the same problem with PHP or any other technology.
I'm not getting the concept web api and session.
I've created asp.net web api project and integrated angularjs in it.Every time I'm gonna call web api.
I have read the articles which state its not good to use session in Web api. I do understand that web api is stateless approach. I do agree. stil there is a way to use session.
First question: If, after login, i want to show user name on every page what should i do with web api approach????
second question: they say don't use session in webapi. then what is the other way/approach to store client information safely.
If I use HTML5 local storage, it can be editable.
If cookie is used, it can be deleted.
What and how should I do it for user till application is in running mode?
This is where semantics often clouds the discussion. People confuse the Session object with statelessness. And often say: 'don't use session because it isn't stateless!'.
However they really mean that you should strive to have your the restful calls to be idempotent, meaning they don't change their behavior depending on whatever it is you do in the background.
Session, or the runtime-cache, or whatever it is you use to cache data, has no effect on your stateless design, because really, what's next? Your database is statefull too? And you shouldn't read data from that? Nonsense obviously; your underlying storage, if it's in-memory or on disk has no reflection on your state to the client.
Although I feel #MajoB makes other valid points about not using the session object, there is really no harm using some kind of cache in the web api, session or something else. But never let the fact if something is IN session return a different result then when something is OUT of session.
I would recommend you to avoid asp.session because it may cause performance issues and can expire anytime regardless of your application state, does not scale on cloud, it will block concurrent ajax requests). Better approach would be to use HTML 5 storage mechanism especially in conjunction with AngularJs (you can use ng-storage https://github.com/gsklee/ngStorage).
I would recommend you use asp.net identity and render user information on server.