I am trying to make a online chatting application.
How do I make a variable persist across users logged in from machines from different places in PHP?
I tried using session_write_close method but didn't work out.
Please guide with a step by step procedure. Many thanks.
Sessions are per-browser. The session id is most commonly stored in browser cookies, or it can be passed around directly with each request. Either way, you cannot use the same session on different computers, not even multiple browsers on the same computer.
Instead of persisting the session, you can persist variables the same way you store user configurations, for example by saving settings in a database. The variables you want to store should be tied to the user account, not to the session.
Related
As with many other founders and their start-ups, I'm low on cash and aiming to launch without funding. The app will be dealing with users health data so setting up a server with the correct encryption may be costly. I am also only familiar with JSON, SwiftUI, Swift5 and API programming so setting up a server is outside my scope of expertise.
Therefore, I aim to launch the app with all user data stored locally in SwiftUI CoreData, as to avoid these issues. With enough users i.e. traction, I will then begin to seek funding, at which point I would hope to set up an encrypted server and transfer user data there.
I am worried that if I launch with local storage, I will not be able to transfer each individual users data to an external server, without them having to reenter all of their information.
I was just wondering whether this was possible or not? And if you could provide details that would be very helpful.
My whole interest in PostgreSQL is driven by its ACL system which is really powerful.
To access the data in a Scala application I have two options in mind EBeans/JDBC or Slick FRM.
Our application is an enterprise one and has more than 1000 users, who will be accessing it simultaneously, having different roles and access permissions. The current connectors, I am aware of, ask for database username/password at the time of connection building, and I haven't found these providing any facility to change the username/password on the fly as we will be getting the user reference from session object of the user accessing our server.
I am not sure how much the title of the question makes sense, but I don't see recreating(or separately creating) a database connection for every user as an efficient solution. What I am looking for is a library or toolkit which lets us supply the interacting sub-user/ROLE in options parameter using which PostgreSQL can do its ACL enforcing/check on data/manipulation requested.
You can "impersonate" a user in Postgres during a transaction and reset just before the transaction is done using the SET ROLE or SET SESSION AUTHORIZATION commands issued after establishing a database connection.
I need add multi-user capability to my single-page mobile app developed with Ionic 1, PouchDB and CouchDB. After reading many docs I am getting confused on what would be the best choice.
About my app:
it should be able to work offline, and then sync with the server when online (this why I am using PouchDB and CouchDB, working great so far)
it should let the user create an account with a username and password, which would then be stored within the app so that he does not have to log in again whenever he launches the app. This account will make sure his data are then synced on the server in a secure place so that other users cannot access it.
currently there is no need to have shared information between users
Based on what I have read I am considering the following:
on the server, have one database per user, storing his own data
on the server, have a master database, storing all the data of all users, plus the design docs. This makes it easy to change the design docs in a single place, and have them replicated on each user database (and then within the PouchDB database in the app). The synchronization of data, between the master and the user DBs, is done through a filter, so that only the docs belonging to one user (through some userId field) are replicated to this user's database only
use another module/plugin (SuperLogin? nolanlawson/pouchdb-authentication?) to manage the users from the app (user creation, login, logout, password reset, email notification for password lost, ...)
My questions:
do you think this architecture is appropriate, or do you have something better to recommend?
which software would you recommend for the users management? SuperLogin looks great but needs to run on a separate HTTP server, making the architecture more complex. Does it automatically create a new database for each new user (I don't think so)? Nolanlawson/pouchdb-authentication is client-only, but does it fit well with Ionic 1? Isn't there a LOT of things to develop around it, that come out of the box with SuperLogin? Do you have any other module in mind?
Many thanks in advance for your help!
This is an appropriate approach. The local PouchDBs will provide the data on the client side even if a client went offline. And the combination with a central CouchDB server is a great to keep data synchronized between server and clients.
You want to store the users credentials, so you will have to save this data somehow on your client side, which could be done in a separate PouchDB.
If you keep all your user data in a local PouchDB database and have one CouchDB database per user on the server, you can even omit the filter you mentioned, because the synchronization will only happen between this two user databases.
I recommend SuperLogin. Yes, you have to install NodeJS and some extra libraries (namely morgan, express, http, body-parser and cors), and you will have to open your server to at least one new port to provide this service. But SuperLogin is really powerful to manage user accounts and user databases on a CouchDB server.
For example, if a user registers, you just make a call to SuperLogin via http://server_address:port/auth/register, query the user name, password etc. and SuperLogin not only adds this new user to the user database, it also creates automatically a new database only for this user. Each user can have multiple databases (private or shared) and SuperLogin manages the access rights to all these databases. Moreover, SuperLogin can also send confirmation emails or resend forgotten passwords (an access token, respectively).
Sure, you will have to configure a lot (but, hey, at least you have all these options), and maybe you even have to write some additional API for functionality not covered by SuperLogin. But in general, SuperLogin saves a lot of pain regarding the development of a custom user management.
But if you are unsure about the server configuration, maybe a service such as Couchbase, Firebase etc. is a better solution. These services have also some user management capabilities, and you have to bother less with server security.
I have a website which runs in Perl cgi files. When a user logs in it creates a new session using Perl CGI::Session.
The problem comes from accessing two duplicated websites located under different user directories. For example, www.abc.edu/~AAA/project/ and www.abc.edu/~BBB/project/
These are exactly the same website on the same machine, so they share the same /tmp directory.
When I login to AAA's website (~AAA/project/*), it creates a session cookie on my
computer, in which the domain name is abc.edu. Then it creates session
information in /tmp directory which is owned by ‘AAA’, because the owner of the script is supposed to be 'AAA'.
Then if I access BBB's website (~BBB/project/*), it tries to use the session info
stored on my computer because the domain name is the same. However,
the session info stored in /tmp is owned by ‘AAA’, it cannot read or write the session information.
[edit] This is like A/B testing websites, and I agree that they should not share the sessions information.
I am thinking that the session information stored in /tmp should be readable and writable by anyone in this case to resolve the issues.
[edit] I realized the security issues that #simbabque pointed out, and also I found that -path parameter of session cookies can be used to differentiate those two groups of users. So now my question is what if I indeed want to use common authentication system between those two website, how can I share the session information without causing security issues? What is the typical way to handle in this A/B testing and shared authentication system? Thanks for your helps.
I was planning to write a long answer with an example application, but after rereading your comments and the question I think the answer is rather simple:
If you intend to use one login mechanism and the site's users are aware of this, then there is no security concern. It's being done all the time. A lot of systems today are made up of more then just one program to form one application, and they need to do that.
If the ownership of the files in the temp directory is a problem because the applications run as different system users, then simply don't use files as the session storage. Use a database or a key/value-store for example.
Or you could put both users into the same group and make the files group-read-writable. There are a lot of solutions here.
I am building a large application and I ususally use a simple session to store private global information however as the application could be rather large I belive this could be a problem due to the amount of memory sessions it could have.
Is there a better way to store such variables?
For example, when the user logs in I want to store data about that user and display it where needed without having to query the database each time.
Sessions are the way to go here, they are intended to persist information about the current session across requests. There is no other object in the ASP.NET framework that has this intention.
You could use the Cache, or store in the Application collection, but then the responsibility of uniquely identifying the individual session data is up to you.
What's also up to you is handling when the session terminates, and freeing up the instances that are stored in those collections (Cache or Application).
It's really a bad idea to start to ask these questions based on what you might "think" will happen. This is a form of premature optimization, and you should avoid it. Rather, use Sessions, as they were intended for this purpose, then measure where your bottlenecks are and address them, should performance be an issue when testing.
use cookies - they would work irrespective of your load balance environments
other options include:
1) writing your sessionvalues to a sql database - you can configure your asp.net app to configure session state to use sql server - but this has its own problems as sessions never time out (so u need to handle this via code explicitly)
2) if not using sql server - basically you would face a problem when you have too many users and you implement load balancing on your web server - so a user can go to a different web server in the same session (and it would not work)
there is a work around for this too - its called STICKY SESSIONS - where your web server guarantees your user would always hit the same web server within the session
3) with .net 2.0 provider model, you can even write your own session storage provider by implementing their delegates - so you can create your own xml files on your web server / shared server to read / write session data there :-)
so there are many ways you can solve this. however the simplest and cost effective solution is to use cookies
You might use Cache. That has built-in mechanism to free up when memory is running out...
Definitely use cookies for this. The best approach is to make yourself a cookies wrapper class that will do all the heavy lifting for you - checking if cookie is null, accessing the httpcontext, etc. No need to mess up your code with all that; just abstract it all out into cookies.cs or .vb.
SetCookieValue(someValue, cookieName); //there will be some expiration concerns here as well
myValue = GetCookieValue(cookieName);
Christian Weiss has a good strategy.
If you think your data is too large for the Session, I would consider a database of some sort using cache so that you don't unnecessary calls.
If it is per-user-session data you're storing, using the ASP.NET Session is definitely your best bet. If you're most worried about memory usage then you can use MSSQL mode. The data has to live somewhere and the choice of which session mode to use is dependent on your environment and the usage patterns of your users.
Don't assume there will be a problem with the size of session state until you see such a problem and have tried to solve it. For instance, it's possible that, although the application as a whole may use a large amount of session state, that any given user may not use that much in the course of a session.
I's also possible that changing from the default session state provider to the SQL provider or state server provider would ease a memory issue.
You can use Cache, but Cache is application-wide. You would need to qualify Cache entries with the user id or session id: Cache[userID + ".MyCacheEntry"].
Do not, under any circumstances, use static variables to store this data. As suggested by your subject line, they are application-wide, not per-user.