I do have a sensitive user input entered by user. When user submits the page, it will sent to second server (https) (to which sending this sensitive data is fine) through javascript form submit. After that server process some, it will be returned to main server(https) with that sensitive input.
Problem here is, I cant bind this input to beans deployed in my server (as my server is not compliance certified). So when second server posts the values back, it is getting lost as it is not bonded. It may be really bad situation, but this is what happens.
Please help. Thanks in advance.
You could put the value in session scoped variable.
Related
I am facing a strange issue:
I have a page with an email field in it when I submit the page the control goes to a servlet where I am saving the email value in session by using
request.getSession().setAttribute("email_Value", request.getParameter("email_Value"));
Now, on the basis of this email value I lookup the database and extracts the information for this user if information found then remove the session attribute by
request.getSession().removeAttribute("email_Value");
if not then redirect the request to same page with an error message and prefilled email value which I am extracting from session using
if(null!= request.getSession().getAttribute("email_Value")){
String Email = (String)(request.getSession().getAttribute("email_Value"));
request.getSession().removeAttribute("email_Value");
}
It works fine on our deleopment, UAT environments but problem is coming only on PROD where we have load balancer.
The issue is that while coming back to the same page it change the email address field witch some different email value which I have not even entered on my machine i.e. it is accessing someone else session.
Could someone provide any pointer to resolve this issue. As this is Production issue, any help would be appreciated.
Thanks
looks like you need to use sticky-sessions. This must be configured in the apache
Http is a stateless protocol meaning, the server doesnt know to identify a client over a period of time.
When a client makes a call to the server (load balanced, say server_1 & server_2), it could reach either server_1 or server_2, assume the request reaches the server_1, now your code creates a session and adds the email to the session.
When the same client makes another call to the server, this time it hits server_2, the email which is in server_1 session is not available to server_2 and server_2 might have email from another session thats why you are seeing another email address.
Hope its clear.
Solution:
URL Rewriting
Cookies
If your application is deployed on multiple servers, chances are there that your sessions may get transferred between servers. Also, in such scenarios, if you are storing any objects in sessions, they HAVE TO implement Serializable interface. If they don't, then the data will not be persisted when the session gets migrated.
Also, it seems that the session gets interchanged with another one. Are you storing anything at Application level?
I would also advice you to look into HttpSessionActivationListener for your case.
I am developing a web application that needs to prevent multiple login using the same user name and password concurrently.
If it happens on the same machine then we need to do something with the user session, but it should also prevent if they are login on different machines using the same user name and password.
What can be the best approach :-
1) should i store the user session,credentials,and IPAddress of the machine in the DB.
2) should we use the session tracking mechanism in the application itself.If so what is the best approach?
Also , We have to keep following things in mind:
1) If user close the browser without logout.
2) If session times out.
Hope it clears the question.
Besdies data base hits (which could fail if your server is broguth down without updating db) : A data base friendly way is not to hit the data base for every re login or you could get denial of service attacks that brig you dowm. Instead implement a session listener in J2EE and check if same user is logged in by looking up the user id in a cache.
If you have more than one app node then need a distributed cache with a time out same as session time out in web.xml.
Simply have a field in your database that has text that says online or offline for each user, according to whether they are logged in or not. So when someone tries to log in with that username, check the database if the field says online for that given user on submit. If the field says online, don't allow log in. Otherwise permit it.
without using a database
you can store if a user is online in a text file
$check= "onlineCheck.txt";
$fh = fopen($check, 'a') or die("can't open file");
$nowOnline= "USER678 \n";
fwrite($fh, $nowOnline);
Phase 1: I succesfully confirm the user password in a web form using HttpClient and HttpPost.
In this case, the code I receive from the server is 200OK.
Phase 2: Now, let's say the user will attempt to confirm his password again. But he can't do that,
because the initial URL won't exist anymore, so he will be redirected to the login page.
Here's a bit of a difficulty: in this case, server responds again with 200OK, not a redirect code.
How can I differentiate between the first phase and the second?
I tried
serverResponse.getStatusLine().getStatusCode();
and
serverResponse.getLastHeader("Location").getValue();
without luck, as there's no real redirect happening from the server point of view.
I thought about getting the response content and parsing it as html, but I believe that's not a good solution.
I also thought about storing in a boolean SharedPreference the confirmation action, but then there's the case when the user has multiple devices.
Another possible solution is to hide the confirm password fragment, once the user confirms his password.
What do you think it would be a good way to differentiate between phases or to prevent phase 2?
I appreciate any idea.
Thank you.
Summary
In our web application when the user clicks "faster" than the page loads, apparently the browser shows the first request to the user (according to some error messages we get). I would have expected that to be the second request.
More background information
We have a Struts1 web application. In the user session we put the current context of the user interaction.
request.getSession().setAttribute("context", <something>);
For instance, the app shows a list of master records, and the context holds information about the user. When the user clicks on a master record, we save the the information about that record in the user session object. In the JSPs we often would assign the context object to a local variable. This needs casting to the specific type (e.g. MasterRecordDTO or UserDTO):
<% MasterRecordDTO dto = (MasterRecordDTO) request.getSession().getAttribute("context"); %>
The user can then drill down into details views of that master record. We have a breadcrumbs showing sth like list > master > detail. These are links so the user can navigate using breadcrumbs.
Now when in that situation the user clicks first on "master" and quickly enough on "list" he gets an ClassCastException saying
"UserDTO cannot be cast to MasterRecordDTO"
in the MasterRecord-JSP, which means that when the MasterRecord-JSP assigns the dto variable in the first request, the second request has already set the context session attribute to a UserDTO object.
Question
I would have expected that the browser would "abandon" the first request and shows the result of the second request to the user (the list of master records in this example). Can anybody explain this to me?
Update
The breadcrumb links are in another HTML Frame. We have this issue with Internet Explorer 7. I tried it with Firefox 11 but apparently it doesn't even submit the second click.
I guess it's a general concurrent programming situation.
The browser send 2 request simultaneously to server, the server use 2 threads to handle 2 request.
request/thread 1 set session attribute context to MasterRecordDTO
request/thread 2 then changed it to UserDTO (Here's the source of the problem)
request/thread 1 continue running, it will cause ClassCastException occured.
request/thread 2 continue running, it will generate a successful response to client. (but the browser does not show it)
The behaviour of browser is not controled by your application, it just show the result of response 1 (sometimes may be response 2, it's also a concurrent situation, because most current browsers are multi-threading designed).
Try to use request scope to store such context information to get an expected result.
I have a jsp page in my project where user fills up the details for creating an account.
when a user enters username and clicks on the check button, the button looks in the database if the same name exists or not(it is able to check because of the servlet code).
If username exists it shows not available.
Now the problem is even if username is not available when user clicks on sumbit button with existing username the details get saved. how to correct this?
(I'm nt able to post image otherwise it would have been more clear.)
Just add an if-else block to your servlet, something like this:
if (usernameExists) {
showError();
} else {
saveUser();
}
Do not do this:
if (usernameExists) {
showError();
}
saveUser();
I'd also add an UNIQUE constraint on the username column in the DB so that your DAO throws an SQLException or like.
See also:
Our Servlets wiki page - contains a basic Hello world example with server-side validation
First, you serlvet accepting the HTTP POST must validate the data sent to it, when the user clicks a button, if the receiver doesn't validate the information then bad data will get into your system regardless of what you do in the JSP.
Some people send raw HTTP POST messages from time to time just for fun (I don't know why :) ) to see if bad data can get into poorly written web applications.
Once the servlet accepting the POST rejects bad data, you can have it redirect back to the offending web page, filled out with the information that was sent in the bad request, perhaps highlighting the offending field or fields.
Later on, if you have the time, you can write up a bunch of javascript to pre-check the fields and deactivate the submit button. This saves the back end servlet the bother of receiving so many bad requests; however, you cannot use such a technique to avoid fixing the back end servlet. There's too many ways your servlet could get the POST message that don't involve your specific javascript code working.