For my app I have a server-side database in which I store users and their data. I am wondering how to keep track of which user has which UUID. I want to make sure that only the same user with their own unique UUID can access their data in the database.
What would be the best way to do this?
In your database, create a table where each row represents one particular user. That table would have their permanently assigned UUID, along with name, email, etc.
Some databases such as Postgres and H2 support UUID as a built-in data type. Some databases proved a feature, perhaps as a plug-in, to generate a UUID value. For example, the uuid-ossp plug-in for Postgres. If not, you can generate a UUID in Java.
When creating an account for a user, create a row in that table. When a user logs in, look up their credentials in this table, retrieving their previously assigned UUID.
During the execution of your app, keep that retrieved UUID in memory as a java.util.UUID object. In a web app built on Jakarta Servlet, a good place to keep their UUID would be as an attribute on the Session. See Binding Attributes into a Session in the spec. See HttpSession#setAttribute and getAttribute.
When you write rows in other tables that belong to a particular user, include a column for their UUID. Include their UUID as a criteria in your queries.
You might want to look into multitenancy as a topic.
After authenticating the user (via your favorite authentication process), add a set-cookie response header with the user id (or any other data you deem appropriate) as the value.
Don't forget to set the cookie properties httponly, secure, and samesite.
Related
I want to generate a UPI transaction Id on server side . which will be unique (obviously). i am using Spring boot as server side technology and Mongodb as database.
Thanks in Advance
From https://developers.google.com/pay/india/api/web/create-payment-method :
Important: The transaction reference ID is mandatory and must be
unique for every request. This could be order number,
subscription number, Bill ID, booking ID, insurance renewal
reference, etc.
So it is just a reference to your system. Presumably if someone is buying something from you, you are keeping track of it in some Order table or something in MongoDb, for which you are using a unique (possibly auto-generated) Integer primary key, so just use that.
I want to make a javaEE application when users can register and confirm their email when receiving a email with a link after inserting their data in registration form (name, mail...)
To do that I am going to generate a long and unique key with java.util.UUID, store in a database and then send an email to the user with that key being part of the URL (Example: www.mysite.com/account.xhtml?id=KEY). Then the user will click the link, I extract the key from the URL and check if that key is stored in the DB. If it is, the user registration will be completed.
My question is, when creating that key with java.util.UUID, how can I know that it is a unique key? Should I check if there is another equal key in the DB and if so create a new one until the created key is unique?
What's the chance that a randomly-generated 128-bit integer will be equal to another randomly-generated integer?
If you just need peace of mind, use a primary key and if the insert fails due to a key collision, re-create a new UUID and retry the insert.
There are couple of ways you can do UUID in Java.
Java 5 onwards better practice is using java.util.UUID It is size of the string 36 characters. This link gives you simple example.
This discussion will give you answer to your question. It is very strong. I have never came across someone is complaining about its uniqueness.
But if you adding into DB or using in storage or using through network, size may be matters. So converting to other formats - Bases is good solution (Base64, Base85 etc). Please check this discussion here. You can use apache library org.apache.commons.codec.binary.Base64. Base85 is not safe for URLs.
My recommendation is, if you have may application/session beans/web services (many interconnections other applications and data transfers etc) are creating UUIDs, I prefer to do unique application name padding too. Like APP1, APP2 etc and then decode to other bases. If UUID is 6fcb514b-b878-4c9d-95b7-8dc3a7ce6fd8, then APP1-6fcb514b-b878-4c9d-95b7-8dc3a7ce6fd8 like that...
Though it is off the topic here, BUT When you use a URL like this www.mysite.com/account.xhtml?id=KEY, beware about SQL injection hacking attacks.
I tried to make this as simple as possible with a short example.
We have two databases, one in MSSQLServer and other in Progress.
We have the user DTO as it follows that we shown in a UI table within a web application.
User
int, id
String, name
String, accountNumber
String, street
String, city
String, country
Now this DTO(Entity) is not stored only in one database, some information (fields) for the same user are stored in one database and some in the other database.
MSsql
Table user
int, id
String, name
String, accountNumber
Table userModel
int, id
String, street
String, city
String, country
As you can see the key is the only piece that link two tables in both databases, as I said before they are not in the same database and not using same database vendor.
We have a requirement for sorting the UI table for each column. Obviously we need to create user dto with the information coming from both databases.
Our proposal at this moment is if user want to apply sorting using street field, we run a query in the Progress database and obtain a page (using pagination) using this resultset and go directly to the MSSQLServer User table with those keys and run another query to extract the missing information and save it to our DTO and transfer it to the UI. With implies run a query in one database then other query based on the returned keys in the second database.
The order of the database could change depending in which column(field) the user wants to apply sorting.
Technically we will create a jparepository that acts as a facade and depending on the field make the process in the correct database.
My question is:
There is some kind of pattern that is commonly used in this scenarios, we are using spring, so probably spring have some out of the box features to support this requirement, will be great if this is possible using jparepositories (I have several doubts about it as we will use two different entitymanagers, one for each database).
Note: Move data from one database to another is not an option.
For this, you need to have separate DataSource/EntityManagerFactory/JpaRepository.
There is no out-of-the-box support for this architecture in the Spring framework, but you can easily hide the dual DataSource pair behind a Service layer. You can even configure JTA DataSources for ACID operations.
As you will always need to fetch data from both databases, why not populate local java User objects then sort these objects (using a comparator with the appropriate fields you want to sort on).
The advantage of sorting locally vs doing the sort in the database query is that you won't have to send requests to the database every time you change the sorting field.
So, to summarize:
1- Issue two sql queries for the two databases to get your users
2- Build your User objects using the retrieved values
3- Use Java comparators to sort the users on any field without having to issue new queries to the database.
My advice would be to find a way to link 2 databases together so that you can utilize database driver features without your code being affected.
Essentially if Progress database can be linked to SQL Server, you will be able to query both databases using a single SQL query with a join on id column and you will get a merged, sorted and paginated result set for your application to display.
I am not an expert in Progress database but it seems there is an ODBC driver for it so you might try to link it to SQL Server.
I'm generating a unique id(generated by the frame work used are, so I should use only this ID and there is no API in the framework to check if this generated by the framework. Thanks RichieHH for pointing this) for each request in the web application and this can be presented back as a part of another request to the system. Now, I am storing these unique ID's generated in the database, and for every request the DB query is issued to check if this ID already exists(this is how the validation is done currently for the unique ID's). Now, if I have to validate the ID sent in the request has been generated by the application with out using the persistent storage, which approach should I be following?
My initial approacht is to generate the ID which adds to particular sum after hashing, but this can be identified after going through the patterns.
It will be great if some one can help me with an approach to solve this problem in a way it can validate the uniqueID generated with in the application. Thanks.
Use UUID, which is pretty standard solution for this task. You don't need to validate UUID, you can assume that it is unique always.
You can use ServerName+Timestamp+some extra. It can be more advantageous for debug but less secure.
Is there any way to configure(xml) tomcat (6.x) to generate unique SessionId.
(Without extending ManagerBase/StandardManager).
I am capturing user login details in db table,with Session Id in a column with unique constraint,and am getting unique constraint exception
You should not store the Tomcat-generated session ID as an unique constraint in the DB. This makes no sense. Tomcat's session ID is only unique within all existing active sessions. The Servlet spec does not forbid to reuse the ID of an expired session for a new session at some point, months or years later. With a fixed length 32-char hexadecimal string as session ID, all possible IDs are not "unlimited". You can't prevent it from being reused for a different client at some point.
I do not understand why you would ever store a Tomcat-generated session ID in the DB lifetime long. You should remove it from the DB whenever it has expired. Or you should solve your problem differently. As you didn't state anything about the functional requirement behind this "solution", I cannot give a more suited answer. Here are however some hints:
Do it the other way round: insert or select the necessary data in/from DB, get the DB-generated ID and store it as an attribute of the HttpSession. For example the logged-in user ID, or just the whole User object.
Or, if it needs to expand the default lifetime of a session, e.g. "Remember me" option, then you should generate an UUID yourself (and test if it doesn't exist in DB yet) and use it in a separate cookie instead.
I'm working on this issue myself, and I'd like to mention that it is possible to generate a guaranteed unique ID using 128 bits (32 hexadecimal digits) using UUID. It is based on UTC time, and is guaranteed to be unique as long as the usec timestamps at which different UUID are generated are different.
See also RFC4122: https://www.ietf.org/rfc/rfc4122.txt
Java has a standard class for generating these IDs:
http://docs.oracle.com/javase/6/docs/api/java/util/UUID.htm
Just use a compound primary key, as CONSTRAINT PRIMARY KEY ("SID" , datum);