We Keep Coding

Java: how to check if user clicked-on or replied to email (as part of email authentication scheme)?

I'm hoping not to re-invent the wheel -- I'm fairly new to Java, but I need a simple but robust algorithm/code/software to perform email verification for users of a web application (e.g. I only need help with step 4 below). That is, I need to verify the user logging in has access to the email address he/she provides during log in.
The steps I have in mind for the Java middle-tier would be:
Java POJO receives user's email and password from client.
The POJO talks to a database server to verify the email/password combo is valid.
If valid, the POJO sends an email to the email address, asking user to reply to email (or click on some provided link, etc.)
The POJO receives notification (how?) that the user has replied to email (or clicked on link, etc.).
The POJO informs the web-application of success (or failure) of authentication, thereby permitting or denying access to the application.
I can write everything except step 4. Essentially I need a way to send an email to a user and then receive some type of response indicating the user received the email.
Anyone know how this can be accomplished? If not, what do you recommend as the next best/simplest solution?
I'm not using a framework as my Java middle tier is very simple. I'd like to keep the solution lean (meaning, don't want to install/implement more than I need; Spring seems overkill). I read up Shiro, but didn't find any evidence it supports email authentication. Any advice is much appreciated to help me avoid writing unnecessary/unproven routines.

The easiest way is to have some code that connects to the mailbox of the destination address, using either POP3 or IMAP, and waits for new, incoming messages.
When you send the email, you can add a Message-ID header. When the user replies to the email, there will be a References that should have the Message-ID that the user is replying too.
When you can use this ID to correlate what they are responding to.
For safety, you may wish to embed the ID within the message itself (since most folks today don't edit replies), so you can look through the body of the message if for some reason the Reference header isn't supplied. There are other techniques that let you give each mail a customer Reply-To address, that's another way this can be done, but that requires some mail server support.
But, anyway, once you have the message structure figured out, you simply listen to the inbox of the address, and look for new messages. As they arrive, your strip the Message IDs, and flag them as appropriate in the DB, or whatever.
As for "waiting" for the message, you must appreciate that it can be a long wait. Rather than having a POJO waiting for it, rather have a simple process that pings the status. You can have a timer that fires every second, and then checks the database to see if it's been updated, etc. Obviously, this is something you want to be able to cancel.
For all of the mail needs, you can use JavaMail -- it does all this, and it pretty straightforward to use.

there are two controllers involved (two POJOs).
the first connection, for steps 1,2+3 talks to one object in the server. as part of (2) a unique code (the UUID mentioned in comments)is generated and saved to the database.
the second connection, when the user clicks on the link, goes to another controller (another POJO, which could be the same class, or could be a different class, depending on your implementation). that reads the UUID from the link, goes to the database, finds the email associated with the UUID, and marks the email as verified.
update i'm struggling to see what you are missing, but when the user clicks on a link in an email the operating system opens a web browser. the web browser makes a connection to the server. the server receives the HTTP GET request with the UUID in the URL and passes the UUID to the POJO.
some more terms: the process of handling the incoming request in the webserver is typically called "routing" and the general pattern used to structure the code that is called is "MVC". exact details will depend on the application framework you are using. for servlet-based java code there's a mapping from URLs to servlets (servlets are java code implementing a certain interface - a framework might provide the servlet which ultimately invokes what you are calling a POJO, or you might write the servlet yourself, in which case that would be your POJO, although in that case it's a misnomer since it implements a specific interface) in the web.xml file.
also, i guess, the web browser on the client uses TCP to make a connection across the network (almost always this is on top of a protocol called IP because you are using the internet). on top of this, the client "speaks" messages in HTTP. all these different layers are described in the "7 layer osi network model".
there's a huge amount of detail on so many levels. hope that gets you started.
see also http://www.quora.com/What-happens-when-you-type-a-URL-into-your-browser

difference between forwarding and redirection [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
difference between jsp forward and redirect
Does anyone knows the differences between forwarding and redirection in Http servlets and the impact of these differences on browser refreshes?

forwarding is done without letting client know that, It is used to do internal communication at server, while in redirecting we are asking client go back and ask it over here.
Real life example
Forwarding
You went to postoffice there are number of boxes and person sitting there, now one of them accepts your request and it internally forwards it to other responsible person to fulfil your request and at the end of the process you will get the result
Redirecting
now the same person gives you a token which says goto window no5 and ask that person .
Also See
difference-between-jsp-forward-and-redirect

Read this wikipedia article, which explains it very clearly.
A forward just transfers the responsibility of a single request handling to a new server-dide component (example: servlet --> JSP). A redirect asks the browser to send a new request when a first one has been partially handled (example :create product --> redirect to list of products).
The post-redirect-get pattern, which is explained in the wikipedia article, explains when and why a redirect is preferrable.

fowarding happens on the server side. the server fowards a request to some other page and let that page handle it.
redirection plays between server and client. the server return some HTTP code (dont have in mind now) to the client which tells him the make a new GET request for the page redirected to, this happens without any user interaction.

Forward is transparent to the browser.
Redirect is not. It involves the browser loading a second URL. So I'd assume this is a bit slower.
See here for more info

Pausing and notifying particular threads in a Java Webservice

I'm writing a Java webservice with CXF. I have the following problem: A client calls a method from the webservice. The webservice has to do two things in parallel and starts two threads. One of the threads needs some additional information from the client. It is not possible to add this information when calling the webservice method, because it is dependent from the calculation done in the webservice. I cannot redesign the webservice becuase it is part of a course assignement and the assignements states that I have to do it this way. I want to pause the thread and notify it when the client delivers the additional information. Unfortunately it is not possible in Java to notify a particular thread. I can't find any other way to solve my problem.
Has anybody a suggestion?

I've edited my answer after thinking about this some more.
You have a fairly complex architecture and if your client requires information from the server in order to complete the request then I think you need to publish one or more 'helper' methods.
For example, you could publish (without all the Web Service annotation):
MyData validateMyData(MyData data);
boolean processMyData(MyData data);
The client would then call validateMyData() as many times as it liked, until it knew it had complete information. The server can modify (through calculation, database look-up, or whatever) the variables in MyData in order to help complete the information and pass it back to the client (for updating the UI, if there is one).
Once the information is complete the client can then call processMyData() to process the complete request.
This has the advantage that the server methods can be implemented without the need for background threads as they should be able to do their thing using the request-thread supplied by the server environment.
The only caveat to this is if MyData can get very large and you don't want to keep passing it back and forth between client and server. In that case you would need to come up with a smaller class that just contains the changes the server wants to make to MyData and exclude data that doesn't need correcting.

IMO it's pretty odd for a web service request to effectively be incomplete. Why can't the request pass all the information in one go? I would try to redesign your service like that, and make it fail if you don't pass in all the information required to process the request.
EDIT: Okay, if you really have to do this, I wouldn't actually start a new thread when you receive the first request. I would store the information from the first request (whether in a database or just in memory if this is just a dummy one) and then when the second request comes in, launch the thread.

Implementation of Multiplayer game - Jquery Application Level?

Good day!
I am planning to create a multiplayer board game using java, jquery, dwr, ajax. In my java, i will store data into application level. Using dwr and ajax, I can retrieve data without the need to refresh my browser and do JQuery animation accordingly. My problem is, If there are many players, how can the JQuery animation automatically changes for everyone to see it without the need for them to refresh their browser.
For example, player 1 is on grid(1,1). My code will allow player 1 to go to grid(1,2), grid(1,3) etc. using Jquery with corresponding animation. But the other player(using another browser) will not be able to see this. How can i make the other player see it? Is it possible that the second player is also accessing the browser of player 1 remotely? Any suggestions/books/articles/code samples regarding this would do.
Thank you.

1) You can do it with Ajax by calling ajax calls every second for every user to check if there are changes on board.
2)To not to make many ajax calls you can use Comet.
3)From performance view the best way is to make TCP server and use sockets. You can use Websockets or Flash socket proxy.

Managing webapp session data/controller flow for multiple tabs

I have a Java web application which stores some data in the session. The data in the session changes as the user interacts with the application (e.g. flow is managed by a controller, each controller has several form pages, on each form page some data is updated in the session and flow goes to the next form page).
The problem is that some users are opening more than one tab to the application, each tab with a different step in the flow. At this point data in the session is messed up since the tabs share the same session (app uses cookie managed sessions).
Telling the users to use different browsers to avoid sharing the same session id (e.g. one Firefox window and one IE window) is not an option since surely at some point somebody will forget to do this and instead use tabs, thus messing up their data.
Adding some verifications that detect that another flow is requested from another tab and display a message to the user saying this is not allowed is not an option either since it pisses of the users and we don't want that do we? :D
The fact is that using another tab is useful for the users because they are more efficient in what they use the application for, so I am keeping this option. But the question now is how best to manage the one session data for the more tabs?
What I thought of, was to have the controller generate a token when it starts the flow and pass this token to each form page which in turn sends it back to identify itself. If another tab requests the same controller action when there is an ongoing flow then generate another token and pass that around.
Basically, I want each flow to have a token and inside the session I won't just keep one set of data but have a set of data for each token and then match requests based on the token.
Now the problem is that this approach will need a lot of rewritings to the application and I was wondering if there is a best practice for managing such a situation or can someone suggest other approaches. I am open to ideas.
Have you encountered this situation? How did you handle it?

This is usually done by assigning a windowId for each tab/window and passing it on each request. Jsf supports this via orchestra. Spring mvc will support it in the next version.
I recently needed this for a simple case, so I implemented it myself. Took half an hour. However, my scope was very limited:
pass a windowId with each request, and return it back for the next request. The first time - generate it.
for any attribute you want to store in the session, put a Map<String, Object> where the key is the windowId

This is exactly what Seam was created to handle. In Seam there's a concept called a Conversation which basically does exactly what you are explaining. Conversations are basically are a way to divide the Session into many pieces that can expire at some timeout. You can look at the source code for org.jboss.seam.core.Manager class to see how it's actually implemented and get inspired ;)

Depending on the complexity of your application, you may want to investigate implementing tabs within your application. This gives you wholesale control over the flow, while still providing users with the functionality they want. I'd argue it's, bugwise, the most robust solution, since you won't have a dependency on the way the browser handles sessions, minimising the number of "known unknowns".
Of course, there'll be potentially a large upfront cost to this, depending on how your application is structured. Without more information about your app, you're the best placed person to decide.

You can also try to wrap your application inside Adobe Air
And then limit your web application to be only accessable from this air. By doing this you dont need to consider the web browser fragmentation and their unique behaviour.