I am developing a swing based DEFECT TRACKER application.
The problem is I have to maintain user sessions. I do not have a clue how to do this. Many users may access the system simultaneously and enter their own data. This is a basic scenario seen at many places.
Like any login based application we have.
These are the following answers I can think of:
If the user logs in before performing any activity, you could easily maintain session information based on the login ID.
If there is no necessity for the user to login, you can track the clients connected at the entry point of your application and maintain a map of them. Since each user is not logging in explicitly, you might want to track the clients based on the IP address they are logging in from.
You could assign each Swing client downloaded an unique GUID and send that along with each request.
Of course, the caveat is if there are a lot of concurrent users accessing the system, you have to implement a queuing system and also make sure that your server code is thread safe.
A completely different approach is use to JSPs or Servlets.
Related
I'm looking to implement notifications within my node.js application. I currently use mysql for relational data (users, submissions, comments, etc). I use mongodb for page views only.
To build a notification system, does it make more sense (from a performance standpoint) to use mongodb vs MySQL?
Also, what's the convention for showing new notifications to users? At first, I was thinking that I'd have a notification icon, and they click on it and it does an ajax call to look for all new notifications from the user, but I want to show the user that the icon is actually worth clicking (either with some different color or a bubble with the number of new notifications like Google Plus does).
I could do it when the user logs it, but that would mean the user would only see new notifications when they logged out and back in (because it'd be saved in their session). Should I poll for updates? I'm not sure if that's the recommended method as it seems like overkill to show a single digit (or more depending on the num of notifications).
If you're using node then you can 'push' notifications to a connected user via websockets. The linked document is an example of one well known websocket engine that has good performance and good documentation. That way your application can send notifications to any user, or sets of users, or everyone based on simple queries that you setup.
Data storage is a different question. Generally mysql does have poor perfomance in cases of high scalability, and mongo does generally have a quicker read query response, but it depends on what data structure you wish to use. If your data is in a simple key-value structure with no real need for relational data, then perhaps using a memory store such as Redis would be the most suitable.
This answer has more information on your question too if you want to follow up and investigate more.
I have just started getting my hands dirty with building IM applications with ejabberd XMPP server and I have a requirement to allow one user account to login simultaneously from multiple devices and be able to follow conversations on all their logged in devices much like what gives in Skype, FB.
Is this possible with ejabberd out of the box or are there any further customizations one has to do?
Any pointers I can get woild be helpful. The body of knowledge out there is quite huge and knowing where to start looking has been quite daunting.
Yes, connecting from multiple devices at once is part of the XMPP standard. In a JID, the "resource" portion (e.g.: the part after the slash in jome#stackoverflow.com/desktop) is unique to a single connection and users may have many resources. So the resource could be your MAC or some unique device ID.
Vanilla XMPP allows users to specify priorities with each resource, and messages are routed to the highest-priority resource present. To follow a conversation across all resources at once, you need to enable XEP-0280.
Unfortunately this question may be a little broad, because I can't work out the proper terms to help me bring all this together. I'm very new to php/SQL, and I'm attempting to set up a minimal site with very simple login/register functionality.
Should I be creating a new database user whenever I register a new web user?
Are CRUD privileges safe to give to all users of the website?
Should I actually make a DB user for registering, one which can only insert into the user table and nothing else until they login (requiring no password for mysqli_connect())?
Once logged in, they would make a connection to a different type of DB user, one with more privileges to use the website.
How many different types of DB users should there be?
I assume a small group of users for the DB workers (including one for root access), another group for each type of web user (ie. employers have more privileges than employees), and another restricted user just for registering.
All in all, would >10 DB users in a small website be unusual?
Is there a performance/space cost associated with having many types of users?
I appreciate any responses and links, and apologize if these are very basic questions.
I struggled with this all those years ago, so here is the answer I wish I had:
Generally, this is overcomplicating things, and the headline answer for a basic application is: the permissions of users will be managed by the PHP code in the API calls you make, and one DB user is fine. All users should avoid interacting directly with the DB for app dev generally, to prevent violating the sanctity of the data.
It's good to think about security and restrictions, but simplicity is king - the more complex you make it, the harder it is to maintain, and therefore the easier it is to miss corner cases.
Should I be creating a new database user whenever I register a new web user?
No, database users are distinguished by their privileges. As a result, all users conform to a set of groups with varying privilege levels. The database accounts are separate from the web accounts - connecting to the database is done behind the scenes and has no link to the web account being used.
A good approach would be to create a DB account for each service connecting directly to the DB. For the vast majority, this will be one service, your web server. If the application grows and isolated services such as audits, microservices, security, IOT spring up, they should probably have their own accounts.
Are CRUD privileges safe to give to all users of the website?
The question is misguided - you give the CRUD to the DB account, which will need it. For the CRUD permissions managed inside the PHP, it really depends on your app and specific endpoints. For example, you probably don't want all your users to be able to delete User records, so your PHP code should prevent that from happening.
How many different types of DB users should there be?
The number depends on your database. Generally, there are 4 groups
Database Administrators
Database Designers
Casual End Users
Native End Users
However, if you want to grant table level privileges then you might need to branch out a little more. This would suggest 10 DB accounts is quite a small amount, several hundred is more likely.
The more privileges, the more space is required, but it's a fairly minute consideration, and shouldn't play a big role in performance. Complexity is the next issue - think carefully how many groups and permutations you actually want to test. In the case of the question above, I was a single hobbyist developer - one account as a DBA is probably fine. If there were multiple users directly accessing the DB (already probably a bad idea for app dev), then maybe split out them with varying permissions.
Talking about table level permissions for a simple app is just way overkill!
I need to do a live chat system (with multiple user channels, user permissions and must be included in a site and use accounts from that database) so I thought at this solutions: ajax requests at a predefined time like 1 second, long polling or irc.
The advantages and disadvantages would be:
AJAX advantages:
Easy to implement
East to check permissions for the site users, give rights, set channels, access everything I need from the database
Disadvantages:
Inserts lag by default
Kills the poor server
Can be used only in the specified page (no outside site client exists)
Long polling:
Doesn't kill the server
Less lag
Can be used only in the specified page (no outside site client exists)
Harder to implement
IRC:
Doesn't flood the server
No lag
A user can set a client and access chat from outside site
Don't know how to communicate with my database so I can create channels and give permissions according to my data
Since multiple ajax requests flood the server I can't use that. So between long polling and IRC what do you think it should be better to use?
If is long polling can you please point to a good reference (I used ape - ape-project.org in the past but I was disappointed by its stability)?
If is IRC can you please point me to a reference that shows how to create a connection to my database (mysql) and put the new logged user into a desired channel? For example if in my database I have an entry like name: Gogu, occupation: killer; when Gogu connects I need to put him in the "Killers" channel.
This is how the system works:
I have a catalog of items. An guest user can choose to add an item from the catalog to what we call the inquiry bin. The system keeps track of the items added to the inquiry bin for that particular session. The user can delete items from the bin.
I was wondering what may be the most optimal way of storing these items. Database? Sessions? or Cookies?
Thanks in advance!
Are these inquiry items required to be available to everyone? Or just the particular user that created them?
If they have to be globally available, then you'd have to stick them in the database, with appropriate flag fields to mark them as temporary and which session created them. If it's per user, then it's best to stick them in the session.
Cookies shouldn't be used for major data storage, even if it's just a few items. The less data the client has, the less chance there is to mess around with the innards of your system by feeding bad data via the cookie. If there's just a session ID, then there's essentially no chance of doing anything, other than guessing someone else's session ID.
Client side cookies have best performance, No round trip to web server is a big win for performance. But Cookie has size limitation. see following link about limitation on IE, Other browser should have similar limitation.
http://support.microsoft.com/kb/306070, cookies are used for small amount day storage, like session key.
Session normally means one of server process, if you use on a web farm, Session can not be shared across multiple web server. If you have a single web server, session should be best way to store information on the server side.
For database, it is most flexible solution, but it has performance hit. for high performance website, proper caching is key to go.