Enterprise Client Community

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

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

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...

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

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

Because of dynamic IP assignment, I would prefer the option with the restricted file area.

Markus

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

This sounds very good!

Will I get this parameter through JSF paramValues or through headerValues?

Markus

...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

... just perfect ...

... 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

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);

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