Couchbase Manager for Glassfish: Version 0.2
Friday, June 14 2013
HTTP Headers and JavaEE
Saturday, June 1 2013
OCSP Java Bug (Part II)
Saturday, May 18 2013
Debian 7.0 released!
Sunday, May 5 2013
Glassfish HA using EJB
Sunday, April 7 2013
BUG in Java OCSP Implementation (PKIX)?
Friday, March 15 2013
SPNEGO/Kerberos in JavaEE (spnego.java.net)
Sunday, March 3 2013
Saturday, February 16 2013
SPNEGO/Kerberos in JavaEE (PAC)
Saturday, February 2 2013
SPNEGO/Kerberos in JavaEE
Friday, January 18 2013
MAAK WEBSITE about Glassfish HA using EJB
Mon, 17.06.2013 17:51
Wonderful article! We are linking to this great article on our site. Keep up the good writing.
ricky about SPNEGO/Kerberos in JavaEE
Fri, 07.06.2013 17:56
Hi Aleksadar, It depends on what library you're using. In case of the spnego filter I'm usi [...]
Aleksadar Lukic about SPNEGO/Kerberos in JavaEE
Thu, 06.06.2013 15:16
I set tomcat 7 with spnego on red hat machine and automatic authentification on windows server [...]
ricky about BUG in Java OCSP Implementation (PKIX)?
Tue, 04.06.2013 15:39
Hi Simon, I wrote another entry about this issue and, at least, another one is coming. I'm [...]
Simon Gerber about BUG in Java OCSP Implementation (PKIX)?
Mon, 03.06.2013 15:07
Hey Ricky Thanks for the cool writeup! Did you get any respone concerning the JAVA bug rep [...]
Blind Bat about Debian Multiarch
Tue, 28.05.2013 05:48
Do you really want your blog to be in light-grey on a white background? Its so hard to read [...]
ricky about Debian Multiarch
Thu, 04.04.2013 10:13
Hi Rulet, Usually this is a bug in the distribution packages, I suppose you're using ubuntu [...]
rulet about Debian Multiarch
Wed, 03.04.2013 18:05
Whem trying to install libasound2:i386 it gives an error that /usr/share/alsa/alsa.conf cannot [...]
Friday, June 14. 2013
Going back with my couchbase-manager this week the new version 0.2 has been released. That was long ago when the first version of the manager was made public but I have been waited how several issues evolved. I have to admit that there has not been a lot of movement but I think it is a good time for the second version.
Let's start with the new features in the version:
In the period between the versions there was an attempt to use a different serializer technique. The manager now uses common Java Serializer and it is known that other implementations like Kryo give more performance. Some little tests in order to add Kryo were done but I finally gave up because a lot of internal classes of glassfish require special treatment (objects from cdi/weld, EJBs and so on). Objects of those types need to use the Java Serializer again and I simply thought that the change was not worthy.
The bug about the LDAP realm (the couchbase-manager cannot recover a principal which is stored inside an LDAP realm) was at least updated. Another guy experienced the same problem (but in a completely another way) and the bug was marked to be fixed in version 4.0.1. So I know this is a bug and I will not change the way the manager recovers the principal user from the store when logged.
And finally an annoying behavior still persists when using the non-sticky configuration in the manager. As I have commented several times the deletion of the session cannot be done if the session object had been previously locked (it returns an error). For that reason the only way to delete a session is performing an unlock first and then sending the deletion. Obviously if the session is unlocked weird things could happen and, in my tests, they really happen. I will try to insist on this to the couchbase guys, it should be a way to delete a locked object.
So now you already know, the version 0.2 of the couchbase-manager is out. I encourage all of you to test this new version and comment me or fill a bug in github. I need your comments to check if the manager is minimally usable.
EDIT: I have just discovered that the new glassfish maven repo can be found here. Nice! It is a pity the version 2.0 is just released.
Saturday, June 1. 2013
Today I am going to present a little entry about an issue I found some weeks ago. One Web Single SingOn (SSO) solution, which is already using the old and nice opensso, was planning to move agents from the application layer (JavaEE containers) to the web layer. Until that moment the opensso agents just intercept the requests, perform all the SignOn stuff and insert some information to the application using headers (common user information like identifier, name, email,... And two multi-valued attributes which act as a profile, data to inform the application what the user can and cannot do). Besides a JAR library is used in the applications to isolate the part of the code that interacts with the SSO system.
At first sight the story seemed very easy. Just installing a new agent in the desired web server and removing any agent from the application server. In theory the agent in the front layer can perform exactly the same actions (authentication and header injection) and the library in the applications should work properly without any change. But, as usual, theory and practice are never the same thing.
Two problems came out and needed to be resolved:
The conclusion of this entry is that chaos theory is a matter of fact, that any little change can break your complete solution up, that shit happens. And as I am going to forget this situation very quickly I thought it was nice to write a little summary here. You know that sometimes this blog is just my personal logbook.
Sometimes just fix it and run away!
Saturday, May 18. 2013
As you have already seen in the previous entry, Debian 7.0 is now public and therefore I am using Jessie in testing. Openjdk 7 package is now update 21 (icedtea 2.3.9) and, as I promised, I finally upgraded from openjdk-6 to 7. Taking advantage of the situation I tested the previous OCSP issue I commented in this blog but with the new version.
In 7u21 the issue is exactly the same but presenting different error messages. In the error cases the message presented is the following Signature length not correct: got 256 but was expecting 128. Much more cryptic I have to say than the previous messages (Error verifying OCSP Responder's signature or Responder's certificate not valid for signing OCSP responses).
Checking again the code the problem is still the same. Just the issuer certificate or the configured certificate is passed to the OCSPResponse, so the cases 1 and 3 cannot be mixed with the case 2. But there is a good new, since the following commit the OCSP and OCSPResponse classes accept a list of responder certificates (previously it was only one) and therefore now the fix is even easier. It just consists in adding both certs (issuer cert and configured responder if it is the case) to the list. so now the fix is a simpler patch that only changes the OCSPChecker class.
Talking about the bug I received an answer from Oracle telling me that the BUG has been accepted (it was around two months ago) but I have no more news since then. There is not a public link in the java database either. I am going to try to contact with icedtea guys to see what they think about that.
Keep on trying!
(Page 1 of 26, totaling 76 entries) » next page