This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Email user registration

 
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:The password should only be stored in the DB in hashed from - so it can never be seen in clear text. That's not exposed.

As to how salt provides additional protection, start with Salt_(cryptography). It only makes sense along with hashing: https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification. That also explains why the salt can be stored together with the hashed password.



Hello Tim,

I'd like to clarify, how can we include an activation link which will directly go back to a servlet to validate the password is indeed the User's with reference to the stored hash or salt password in DB ?

Is there anyway not to use a jsp to ask for the password that was just sent like Callback handler?
 
Saloon Keeper
Posts: 21122
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are using J2EE standard security you don't have a login servlet. There is no login code in the web application at all. Instead, the server handles the login. The server presents the login dialog or form when a secured URL request is received, and reads the userid/password. It takes the received juserid/jpassword and passes them as parameters to the Realm module's authenticate() method.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:If you are using J2EE standard security you don't have a login servlet. There is no login code in the web application at all. Instead, the server handles the login. The server presents the login dialog or form when a secured URL request is received, and reads the userid/password. It takes the received juserid/jpassword and passes them as parameters to the Realm module's authenticate() method.



But, the question is not about login.  It is about email activation which I need to verify the 'salted' password.

 
Tim Holloway
Saloon Keeper
Posts: 21122
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have a different question, then you should start a new question thread. It's confusing when a thread's topic changes.

I am not sure if I understand that, but if you're looking to do a web-based registration process with a confirmation email there are a couple of best practices.

One of them is to use an entirely separate webapp to handle the registration. The actual application webapp should not be handling passwords at all.

In the case of a confirmation email, what you do as part of registration is sent an email with a generated link to the address that the user gave to the registration app. The user then has a limited amount of time to click on that link to complete the circle of confirmation. When you do that, neither plain-text nor encrypted password is ever passed back to the client. The confirmation link would simply trigger logic in the registration app that switched the user account from "pending" (cannot log in) to "active".
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:If you have a different question, then you should start a new question thread. It's confusing when a thread's topic changes.

I am not sure if I understand that, but if you're looking to do a web-based registration process with a confirmation email there are a couple of best practices.

One of them is to use an entirely separate webapp to handle the registration. The actual application webapp should not be handling passwords at all.

In the case of a confirmation email, what you do as part of registration is sent an email with a generated link to the address that the user gave to the registration app. The user then has a limited amount of time to click on that link to complete the circle of confirmation. When you do that, neither plain-text nor encrypted password is ever passed back to the client. The confirmation link would simply trigger logic in the registration app that switched the user account from "pending" (cannot log in) to "active".



I am abit flabbagasted by your answer - a separate web app to handle password ?

Could you let me know if the 'separate web App' are you referring to OAuth2 way of authenticating password or I created one myself ?  Do I need a different host for this separate webapp ?

And can I just confirm regarding the full circle way of receiving the link, I do not need a jsp to go back to the servlet right ?  How do I accomplish that ?  I hope you could share with me some tips on this part.

Thank you in advance.

 
Tim Holloway
Saloon Keeper
Posts: 21122
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The reason I recommend a separate webapp to handle user registration is that in order to create a userid/password record in the database, you need specific database rights. Since the password is never passed to the user application in a webapp that's secured by J2EE container security, the user webapp's database user ID should not be permitted to write - or read - the table (or table column) containing user passwords. All database userids for a given connection pool are the same. So in order to use a more permissive user ID to create/update/delete passwords (and read them!), you need to use a different pool. And while you're at it, using a different webapp (classpath context) will further isolate attackers of the user web application from the that privileged connection pool.

You don't really need a separate host for the user account management app, but it doesn't hurt.

When you click the link on a confirmation email, you're basically making a ReST call to notify the registration process to make the user active. So you might display a "welcome" page in response to that request - since every HTTP(S) request does need a response. And that page could be a JSP if you like. Or just plain HTML.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:The reason I recommend a separate webapp to handle user registration is that in order to create a userid/password record in the database, you need specific database rights. Since the password is never passed to the user application in a webapp that's secured by J2EE container security, the user webapp's database user ID should not be permitted to write - or read - the table (or table column) containing user passwords. All database userids for a given connection pool are the same. So in order to use a more permissive user ID to create/update/delete passwords (and read them!), you need to use a different pool. And while you're at it, using a different webapp (classpath context) will further isolate attackers of the user web application from the that privileged connection pool.

You don't really need a separate host for the user account management app, but it doesn't hurt.

When you click the link on a confirmation email, you're basically making a ReST call to notify the registration process to make the user active. So you might display a "welcome" page in response to that request - since every HTTP(S) request does need a response. And that page could be a JSP if you like. Or just plain HTML.



Hello Tim,

I am thinking of making things simpler : I will send out this email to the user.  And there wont be a need to ask for password and storing password.  I need a ahref link back to a servlet which contains the logic and then just insert a verified to the database.

My problem is how to have a ahref link back to the servlet.

Could you help me on that ?

Or it is impossible to have a href link back to servlet directly without going to a jsp or html page first ?
 
Sheriff
Posts: 24654
58
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

tangara goh wrote:My problem is how to have a ahref link back to the servlet.



Does it have to be an href link? If so then you can put HTML in your e-mail and include an "a" element with href pointing to whatever servlet you had in mind. Or you could use an ordinary text e-mail and just put the URL which points to the servlet into the e-mail. All e-mail clients nowadays will turn that into a link.

It's very likely that you have seen e-mails with links in them before.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, it is ok to put www.domain.name/and then follow by this servletclass name ? Will it work?
 
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use whatever link works in an email. Have you tried anything yet?

servlet class name


You should always map servlets with a meaningful name. The class name should not be visible anywhere outside of the web app.

As to keeping a separate web app for handling passwords, I think that would be going quite a way for not much gain. So I've never implemented it that way myself.
 
Tim Holloway
Saloon Keeper
Posts: 21122
131
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You CANNOT "call a servlet" from a web client.

All a web client can do is submit HTTP URL requests.

If the URL matches a pattern that has been mapped to a servlet in your web.xml (or the annotation equivalent), then that servlet will have the URL passed as one of the parameters to the servlets's service() method - which may in turn invoke goGet(), doPost() or whatever.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:You can use whatever link works in an email. Have you tried anything yet?

servlet class name


You should always map servlets with a meaningful name. The class name should not be visible anywhere outside of the web app.

As to keeping a separate web app for handling passwords, I think that would be going quite a way for not much gain. So I've never implemented it that way myself.



I forgot to mention that I am using a context Path name, so it is not the actual class name.

But, the ahref link doesn't work.

So, I still have to point it to a jsp page and then go to the servlet for processing right ?
 
Tim Moores
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

tangara goh wrote:But, the ahref link doesn't work.


What does that mean? What exactly are you trying to do, what are you expecting as a result, and what is happening instead?

So, I still have to point it to a jsp page and then go to the servlet for processing right ?


The other way around: the link would point to a servlet for processing, which would then redirect to a JSP for a confirmation page.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:

tangara goh wrote:But, the ahref link doesn't work.


What does that mean? What exactly are you trying to do, what are you expecting as a result, and what is happening instead?


I got a HTTP405 error
The specified HTTP method is not allowed for the requested resource.

What is the problem ?

So, I still have to point it to a jsp page and then go to the servlet for processing right ?


The other way around: the link would point to a servlet for processing, which would then redirect to a JSP for a confirmation page.



Why do I need to direct it to a JSP when I can flash the message if embed it within Servlet?
 
Tim Moores
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not sure what you mean by "flash the message", but yes - you can create the HTML output directly in the servlet. It's just that doing that has fallen out of fashion many years ago in favor of using templating mechanisms like JSP.

I got a HTTP405 error
The specified HTTP method is not allowed for the requested resource.


Does the servlet implement the doGet method? A link from within an email will always use GET.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I got a HTTP405 error
The specified HTTP method is not allowed for the requested resource.


Does the servlet implement the doGet method? A link from within an email will always use GET.

Yes.  I change it to doGet from doProcess and still getting HTTP405 and  HTTP method GET is not supported by this URL

What could be the problem ?
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to add, here's a snippet of the servlet

@WebServlet("/VerifyEmail")
public class VerifyRegisteredEmail extends HttpServlet {

   static final org.apache.logging.log4j.Logger logger = LogManager.getLogger(VerifyRegisteredEmail.class);

   public VerifyRegisteredEmail() {
   }

And the email will contain a link like this:

   String confirm = "https://xx.DomainName.com/VerifyEmail</a>";

 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:Not sure what you mean by "flash the message", but yes - you can create the HTML output directly in the servlet. It's just that doing that has fallen out of fashion many years ago in favor of using templating mechanisms like JSP.

I got a HTTP405 error
The specified HTTP method is not allowed for the requested resource.


Does the servlet implement the doGet method? A link from within an email will always use GET.



Hi Tim,

Thanks so much for your help.  It is 'working' now except that an insert query is not working well.

Including in this servlet, I have a query to insert verify into a DB to indicate that the user who clicked on this confirmation link is verified.

I am not seeing any data though.  

Can I know if I am using doGET() will the insertion work or not ?

Hope to hear your advice.

Thanks again.
 
Tim Moores
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

tangara goh wrote:Can I know if I am using doGET() will the insertion work or not ?


Have you printed out the exact SQL that gets executed? Maybe it's different than you expect. If you have, and it looks correct, try to run it manually against the DB.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:

tangara goh wrote:Can I know if I am using doGET() will the insertion work or not ?


Have you printed out the exact SQL that gets executed? Maybe it's different than you expect. If you have, and it looks correct, try to run it manually against the DB.



I think I know my mistake now.  There is something wrong with the  schema.

Thanks for your prompt reply.  Really appreciate you for helping me so much.

BTW, the way I do my email confirmation is it ok ?

I mean I am not following the convention of storing hash and then decrypt it to compare the hash blah blah blah.

Is it safe to have it the way I wanted ?

Keen to hear your opinions.

Thanks again.
 
Tim Moores
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

tangara goh wrote:I mean I am not following the convention of storing hash and then decrypt it to compare the hash blah blah blah.


Hashing the password so it can never be decrypted is the minimum you should do.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:

tangara goh wrote:I mean I am not following the convention of storing hash and then decrypt it to compare the hash blah blah blah.


Hashing the password so it can never be decrypted is the minimum you should do.



Hi Tim,

I just want to make sure I get your point correctly.

So, now I send the confirm link together with a hashed password like this :

Please confirm:https://www.xxx/verifyEmail </a>$2a$12$VjnwR3pIonv7x/yejpOFouP0CtmDctvmYgPaDEtg7JplvCYPND1N.

And if I am directly bringing the user to the servlet page to insert the verified and their email id.

Will that suffice ?

Or is there anyway the servlet can read the return HashPassword is the one that is indeed from that email user without asking them to enter into a jsp field box?


 
Tim Moores
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Under no circumstances should you send passwords around in emails, hashed or not. What would be the point of that? You already have the hashed password in your DB, the link is simply about activating the account.
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:Under no circumstances should you send passwords around in emails, hashed or not. What would be the point of that? You already have the hashed password in your DB, the link is simply about activating the account.



Perhaps I have not explained myself clearly or read your last message about having that hashed password.

Now, I do not need to have my user to log in at all so no password is needed.

Thus, I just need them to send back the activation link and that's it.  So, why did you suggest about the hashed password then ?
 
Tim Moores
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm totally confused now.

tangara goh wrote:Now, I do not need to have my user to log in at all so no password is needed.

why did you suggest about the hashed password then ?



I did not start talking about passwords, you did:

tangara goh wrote:I'd like to clarify, how can we include an activation link which will directly go back to a servlet to validate the password is indeed the User's with reference to the stored hash or salt password in DB ?



Also, if the user doesn't need to log in, what is being activated here?
 
tangara goh
Ranch Hand
Posts: 558
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:I'm totally confused now.

tangara goh wrote:Now, I do not need to have my user to log in at all so no password is needed.

why did you suggest about the hashed password then ?



I did not start talking about passwords, you did:

Hello Tim,

I am really sorry I created such a mess here.  I decided that password is not important here since the user doesn't need to log in.  The other type of users then need a log in using REST api - so then include a hashpassword in the password activation link via email  ?

tangara goh wrote:I'd like to clarify, how can we include an activation link which will directly go back to a servlet to validate the password is indeed the User's with reference to the stored hash or salt password in DB ?



Also, if the user doesn't need to log in, what is being activated here?



So, the purpose of the activation link is merely to verify that the user is indeed from the email that she/he claims to be.

So, hashpassword should not be included in the link and I just make them activate the link and then I will insert that this guy is verified in the db.  Will that do or do you think this arrangement is uncalled for ?

 
Tim Moores
Saloon Keeper
Posts: 5802
146
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It sounds about right. But you would insert the data in the DB first (so it's there when the activation link is clicked), and merely set an "activated" bit to true.
 
Your mind is under my control .... your will is now mine .... read this tiny ad
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!