Author |
Message |
31/03/2009 10:09:54
|
moebus
Power User
Joined: 21/11/2007 12:49:18
Messages: 93
Offline
|
is there any preferred way to identify the users computer on a subsequent session. This may not always be identical to a "user name".
In browser environment a persistent cookie would be used for this - while such cookies have a questionable reputation in "internet" scenario, they come in very handy in a trusted environment.
It looks like such cookies are explicitly not handled by captain-client (in class DataTransfer). Can this be customized, or is there any other preferred way to achieve this goal.
regards
Manfred
|
|
|
31/03/2009 12:19:26
|
mreich
Power User
Joined: 30/01/2009 08:34:23
Messages: 744
Offline
|
Hi Manfred,
I would use the JSF context like this:
FacesContext facesContext = FacesContext.getCurrentInstance();
String cookieName = null;
Cookie cookie[] = ((HttpServletRequest)facesContext.getExternalContext().
getRequest())
.getCookies();
theres an example at http://www.roseindia.net/jsf/RememberMeLogin.shtml
regards
Markus
|
|
|
31/03/2009 12:25:11
|
moebus
Power User
Joined: 21/11/2007 12:49:18
Messages: 93
Offline
|
thanks for the info, this was already one of my ideas.
But then come our captain and invokes
Code:
setCookiePolicy(CookiePolicy.ACCEPT_NONE);
and this is probably why it does not work.
So I think we need an official hook here...
|
|
|
31/03/2009 12:32:08
|
mreich
Power User
Joined: 30/01/2009 08:34:23
Messages: 744
Offline
|
ok, I found the entry
http://www.casabacdemo.com/forum/posts/list/342.page
let's wait for the captain, in my application cookies are planed as well
Markus
|
|
|
31/03/2009 18:41:14
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
Hi,
thanks for already discussing!
CaptainCasa definitely uses no cookies. They always cause problems (that's nothing new...) when running the Enterprise Client from the browser: it was unbelievable - but the session cookie was sent, even though CaptainCasa 100% does URL rewriting (the ";jsessionid=...."-thing). We then told the context explicitly to not use cookies (that's were Markus post is referring to) - but this method worked not so great for other deployment environment like BEA.
So, "in the meantime" (> 6 months ago) by default the cookies are not event not sent, but are even removed when data is transferred from the client to the server. From this point of time, when adding the corresponding statement when sengin data...
Code:
conn.setRequestProperty("Cookie",null);
...we had quietness in the box (Ruhe im Karton).
As consequence there is currently no perfect way of re-identify the client's computer.
Since this week (not yet in the update of Monday) the http-header contains the ip-Address of the client as http-header-Parameter, so you can access this info from the http request. Would this be sufficient from your perspective?
If not: applet and webstart allow to write data into a restricted file area, so we can cerate a non-visual-component writing/reading data out of this area.
Please feed back.... thanks!
Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
01/04/2009 07:41:59
|
mreich
Power User
Joined: 30/01/2009 08:34:23
Messages: 744
Offline
|
Because of dynamic IP assignment, I would prefer the option with the restricted file area.
Markus
|
|
|
01/04/2009 08:20:22
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
OK, so what we will do is: we provide one unique client identifier, that is sent afterwards as request-header-parameter ("eclnt-id"). We internally will use the cookie mechanism on client side for storing this value, so we do not open up a new battler field for storing client information.
Dependent from this client id now the application can store information on server side about this client.
So we internally use cookies (as storage medium) but do not open up the stroring of any type of information on client side.
We do not have great experience with the client-side CookieHandler class yet, but think that this should work as described.
Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
01/04/2009 08:38:10
|
mreich
Power User
Joined: 30/01/2009 08:34:23
Messages: 744
Offline
|
This sounds very good!
Will I get this parameter through JSF paramValues or through headerValues?
Markus
|
|
|
01/04/2009 09:12:26
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
...will be part of the http header:
Example:
Code:
POST /demos/faces/workplace/workplace.jsp;jsessionid=6CD78608A585E0C5C6794C37E722C603 HTTP/1.1
Accept-Encoding: gzip
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
eclnt-language: de
eclnt-country: DE
eclnt-orientation: ltr
eclnt-font: Tahoma
eclnt-timezone: Europe/Berlin
eclnt-client: applet
eclnt-ip: 192.168.178.21
eclnt-id: ID_4420_1238570051842
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_12
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 257
Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
01/04/2009 10:03:12
|
mreich
Power User
Joined: 30/01/2009 08:34:23
Messages: 744
Offline
|
... just perfect ...
|
|
|
01/04/2009 10:54:18
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
... little update on this discussion: we did not find a good way to persist data in the client environment. Unfortunately cookies are not really access-able from applet and webstart processing; there is an applet context to write data to the client, which is not available on webstart. ...and with applet context we made not perfect results in IE environment (browser crash after accessing). With webstart there is a PersistenceService (not available with applets) - and then we still have the stand-allone client (by application).
So... the solution now is: the client now has a start parameter ("clientid"). This is the parameter that is transferred in the http-header.
The start parameter is set within the .ccapplet / .ccwebstart servlet. And there... it is taken from a cookie. So, the starting point, which is the .ccapplet or .ccwebstart URL, that is requested by the browser is the one to do the cookie management - here we are still in the normal browser context. Then the value of the cookie is transferred into the client id field.
Anyway: the result is a persistent clientid (stored as cookie) that comes as "eclnt-id" parameter. So the result is 100% the same as previously discussed.
The solution is available with next update - or from now on, on request.
Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
01/04/2009 12:07:26
|
mreich
Power User
Joined: 30/01/2009 08:34:23
Messages: 744
Offline
|
ok, setting the Cookie will work like this?
HttpServletResponse httpServletResponse = (HttpServletResponse)FacesContext.getCurrentInstance().getExternalContext().getResponse();
Cookie cookie = new Cookie("myCookie", "cookieID");
cookie.setID("123456");
httpServletResponse.addCookie(cookie);
|
|
|
01/04/2009 14:08:37
|
CaptainCasa
Power User
Joined: 21/11/2007 12:23:06
Messages: 5521
Offline
|
The updated version will contain the following example to receive the data on server side.
Code:
public DemoClientId(IWorkpageDispatcher dispatcher)
{
super(dispatcher);
m_currentClientId = HttpSessionAccess.getCurrentRequest().getHeader("eclnt-id");
m_currentClientIp = HttpSessionAccess.getCurrentRequest().getHeader("eclnt-ip");
m_currentClientType = HttpSessionAccess.getCurrentRequest().getHeader("eclnt-client");
}
OK, that's the receiving part... the setting cannot be done through the way you propose, because of cookies are ignored in the Enterprise Client.
So, in order to maintain the cookie, the demo workplace will contain a nice pure HTML page...:
Code:
<html>
<script>
function ccSetCookie()
{
var ccDate = new Date();
ccDate = new Date(ccDate.getTime() +100000*60*60*24*365);
var s = document.getElementById("NEWVALUE").value;
document.cookie = "eclnt-id="+s+";expires=" + ccDate.toGMTString()+";";
document.getElementById("EXISTVALUE").innerHTML = document.cookie;
alert("Cookie was set to: " + document.cookie);
}
</script>
Current cookie: <span id="EXISTVALUE"/>EXISTVALUE</span>
<br>
<br>
Change cookie to: <input id="NEWVALUE" type="text" value="" width="100">
<input type="button" value="Set" onclick="ccSetCookie()">
<script>
document.getElementById("EXISTVALUE").innerHTML = document.cookie;
</script>
</html>
Hope this solution is maybe not perfect, but "good enough"...
Björn
|
Björn Müller, CaptainCasa GmbH |
|
|
|