Develop Reference

can I redirect the page without any request to server in java?

If session expires for specific time which is mentioned in web.xml file of my web application,
without clicking any link, my app need to redirect to the login page. I tried to use Listener class which implements HttpSessionListener, but I am not able to redirect to new page because in normal listener there in no response object(response.sendRedirect("login.jsp")).
thanks,Jampanna

You cannot do this. At least not so easy as you think.
If the session expires, it means, that there was no request from the client browser during the session timeout time. The server even don't know, if the user closed the browser window or was going to toilet, etc.
The HttpSessionListener is a server side only event, there is no client request. It indicates that there were no client requests for that session in the last 30 minutes (if the session timeout is 30 minutes).
As a consequence you cannot redirect the browser window to another site.
As an alternative you can frequently poll from the client's browser. But that would mean, the server side session will only expire, if the user navigates to another side or closes the browser. To avoid this, you could implement your own session timeout. At each poll request you could determine the time of the last "real" request (means no poll request) and then redirect to the login page and manually close the session.
Another alternative would be to use websockets as a backward channel.

Use Spring Security Framework, it has all the machinery to cope with session end/re-login cases
Alternatively you can use javascript for redirecting to login.jsp, something like
function redirectToLogin(){ document.location = '/login.jsp' }
setTimeout( redirectToLogin, 300 );
this might work only for really simple webapps. For RIA you must check the session state via requesting the server

How to verify a wordpress user at a servlet?

I'd like to embed an ajax application into a wordpress site. The ajax application will communicate with servlets running on tomcat. Now the servlets need a way to verify if a request originates from a user that is logged in to wordpress. How does this commonly get solved?
AFAIK, wordpress is stateless and does not use sessions, which makes me curious how a logged in user in wordpress can be tracked.
The second problem is, how can a servlet request wordpress to verify if a given user is still logged in?
Any advice is welcome,
Thank you.

The only thing that you can do is read the cookies. And that will work only if you are using the same domain (or subdomain and the cookies are valid for all subdomains). The session cookie might not give you sufficient information, however. You can't read a PHP session from a Java app, and generally, you can't mix two applications that way.
As a little workaround, you can check with javascript who is the currently logged user (by finding the username in the DOM), and send that with ajax, but that is not secure at all.

GWT RPC Cookie authentication

I'm using gwt on my glassfish server, and I'm attempting to make some of my RPC calls authenticated via cookies. Is this possible? Are there any examples out there of how to code it?

Depending only on the cookie for authentication will make your website/services vulnerable to Cross-Site Request Forging/XSRF/CSRF attacks - read more on that in Security for GWT Applications.
The best way would be to double check the value you get from the cookie and with the one that's been transported to the server by some other means - as part of the request (header, a custom field, etc).
Other than that, there are many tutorials covering the subject - just search for Java (servlet) authentication - it doesn't have to be GWT-specific. The Google Web Toolkit Group also has many threads about the subject.

I assume that you use GWT's RPC servlet for handling requests made by the client.
One option that comes to my mind is to write and configure a ServletFilter which can examine the cookie, before the request reaches GWT's servlet.

You might rethink using cookies as it is a potencial security hole.
Why not put your communication to HTTPS?

Can you not just use the standard 'session' scope, i.e.
request.getSession()
A pattern I use in GWT apps is to have a separate 'old fashioned' login form which sets up the session. The GWT app's host page is then displayed after they have successfully logged in.
If the necessary values aren't in the session, then the user isn't logged in. Your service should return an exception, maybe, which instructs the GWT app to redirect to the login page, or display an error.

Best option for Session management in Java

Best way managing session in Java. I heard that cookies are not reliable option for this as they gets stored into browser and can be accessed later on? Is this correct? If possible please come up with the answers with the coding example.
Which is the best among:
URL Rewriting: Server will add an additional parameter at the end of URL link
Hidden parameter in Form: server will add an additional parameter at every form in HTML
cookie: Server will ask browser to maintain a cookie.

The session management (client identification, cookie handling, saving session scoped data and so on) is basically already done by the appserver itself. You don't need to worry about it at all. You can just set/get Java objects in the session by HttpSession#setAttribute() and #getAttribute(). Only thing what you really need to take care of is the URL rewriting for the case that the client doesn't support cookies. It will then append a jsessionid identifier to the URL. In the JSP you can use the JSTL's c:url for this. In the Servlet you can use HttpServletResponse#encodeURL() for this. This way the server can identify the client by reading the new request URL.
Your new question shall probably be "But how are cookies related to this? How does the server do it all?". Well, the answer is this: if the server receives a request from a client and the server side code (your code) is trying to get the HttpSession by HttpServletRequest#getSession() while there's no one created yet (first request in a fresh session), the server will create a new one itself. The server will generate a long, unique and hard-to-guess ID (the one which you can get by HttpSession#getId()) and set this ID as a value of the cookie with the name jsessionid. Under the hood the server uses HttpServletResponse#addCookie() for this. Finally the server will store all sessions in some kind of Map with the session ID as key and the HttpSession as value.
According to the HTTP cookie spec the client is required to send the same cookies back in the headers of the subsequent request. Under the hood the server will search for the jsessionid cookie by HttpServletRequest#getCookies() and determine its value. This way the server is able to obtain the associated HttpSession and give it back by every call on HttpServletRequest#getSession().
To the point: the only thing which is stored in the client side is the session ID (in flavor of a cookie) and the HttpSession object (including all of its attributes) is stored in the server side (in Java's memory). You don't need to worry about session management youself and you also don't need to worry about the security.
See also:
Authenticating the username, password by using filters in Java (contacting with database)
How to redirect to Login page when Session is expired in Java web application?
How to implement "Stay Logged In" when user login in to the web application

All Java web frameworks support cookies or URL-encoded session IDs. They will chose the correct approach automatically, so there is nothing you need to do. Just request the session object from your container and it will handle the details.
[EDIT] There are two options: Cookies and a special URL. There are problems with both approaches. For example, if you encode the session in an URL, people can try to pass the session on (by putting the URL into a mail, for example). If you want to understand this, read a couple of articles about security and build app servers. Otherwise: Your Java app server will do the right thing for you. Don't think about it.

The cookie just stores the session ID, this ID is useless once the session has expired.

Servlet specification defines the API for accessing/setting session data in standard J2EE application. Also it defines that session data is stored on the server-side and nothing is transferred to the client except the session identifier. There are 2 mechanisms how session id is transferred:
1) request URL e.g. jessionid=....
2) cookie
Mechanism is determined automatically based on client capabilities.
EDIT. There is no best option, there is servlet specification that defines the way.

Http is a stateless, client-side pull only protocol.
To implement a stateful conversation over it, Java EE Web Server need to hide some information (which is sessionid) in client-side and the mechanism it can use should follow HTTP and HTML spec.
There are three ways to accomplish this goal:
URL Rewriting: Server will add an additional parameter at the end of URL link.
Hidden parameter in Form: server will add an additional parameter at every form in HTML.
cookie: Server will ask browser to maintain a cookie.
Basically, modern web server will have a "filter" to choose which way to use automatically.
So if Server detected that browser already turn off cookie support, it will switch to other ways.

2 important questions:
Which web technology are you using? JSF, Struts, SpringMVC or just plain servlets/JSPs.
Servlets/JSPs already give you the session support you need. JSP Example: Hello, <%= session.getAttribute( "theName" ) %>
I really don't think you have something to worry about cookies, since the data is stored safely in the server and handeling the cookie is done automaticlly.
Is your application installed on a single server?
If YES than you have no problem, use the servlet session option.
if NO than you gotta find another way to do this. Like using a sticky session, or maybe parse the entire session object in the requests/responses as a field. This option indeed requires you to take security measures.

Sending a HTTP POST request

To implement single sign off, i would like the user to get logged out of application B additionally when ever the user clicks logout on application A. Is it possible to implement this using some form of a POST request to application B? i.e. when the user clicks on logout:
Generate existing POST request to logout of application A
Generate additional POST request to logout of application B as well.

The cleanest way to do this is to check if your SSO provider has a single-sign-off feature.
Coding this up and deploying it would make your overall IT solution a bit brittle.
Another suggestion is to take this up with your (Enterprise) architect as SSO is usually an enterprise initiative and point her to (very cogent) arguments in this post : http://lists.danga.com/pipermail/yadis/2005-July/001085.html

Yes, how you do it depends on the programming language you are using.
For example under ASP.Net you'd use System.Net.HttpWebRequest within the handling of the Logout event of application A to make a logout request to application B
If you can post what language you're working in I can give a proper example

Depending on the implementation of your authentication system, probably you can/need to send the POST using JavaScript instead of from server-side.

Without specific information, it's hard to give a specific answer, but as you're refering to POST, I'll assume a browser is involved.
POSTs (without using Javascript or similar) occur when a form is submitted. As the form can have only one action, it can only target one server-side page.
One solution is to simply have Application A forward sign-out credentials to Application B once one action is received, which allows for more opportunities to check returns.
If, however, you're set on POST'ing to different pages, see this tutorial for one iframe-related hack - http://www.codeproject.com/KB/scripting/multiact.aspx

If your login session is stored by a cookie, and there are nothing else you need to supply to log out of application B, clearing the cookie in javascript will usually destroy the session and sign the user out.

How about making it a cookie based authentication? A same cookie authenticates a user for various applications (in your case 2 different application.) Once a user sign off from one application (app A), invalidates a cookie (by expiry date) so that whenever a user sends a POST request to rest of the application (app B) the request is not processed. A Servlet that traces each POST request to validate the cookie is required for each application.