View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002463SOGoWeb Mailpublic2013-10-22 19:142013-10-23 13:13
Reportervbonamy Assigned Tojraby 
PriorityhighSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version2.0.6b 
Summary0002463: SOGo + SSO CAS - CAS session expiration -> CPU 100%
Description

We have a SOGo with CAS Authentication here.

Sometimes, we have SOGo processes that take 100% CPU.
If the WatchDog of SOGo doesn't kill them we have to do it ourself manually.
Actually we made a script here to do this kill :/

Before to kill it, if we make a lsof on the process, we can see something like :
sogo.mon-univ.fr:57780->cas.mon-univ.fr:https (CLOSE_WAIT)

Steps To Reproduce
  1. We go on the sogo webmail, so we authenticate ourself on the CAS and we can read our mails.
  2. We logout on the cas server directly (but not on the webmail) : we call something like https://cas.mon-univ.fr/logout
  3. We refresh the webmail -> the SOGo process takes 100% of a CPU.
Additional Information

CAS Server 3.4.7
Dovecot

TagsNo tags attached.

Activities

vbonamy

vbonamy

2013-10-23 10:03

reporter   ~0006161

We investigated more and we found that the request from SOGo to CAS server was like :
https://cas.mon-univ.fr/serviceValidate?ticket=ST-350172-AQE0U0DmsB1DXyRrPgg6-localhost&service=https%3A%2F%2Fsogo.mon-univ.fr%2FSOGo%2Fso%2Findex&pgtUrl=https%3A%2F%2Fsogo.mon-univ.fr%2FSOGo%2FcasProxy

which returns here an Error 500 on our CAS Server (V. 3.4.7).

On CAS server, we have effectively in logs :
SEVERE: Servlet.service() for servlet cas threw exception
java.lang.IllegalArgumentException: resourceOperatedUpon cannot be null

The corresponding ssue on the CAS is here :
https://issues.jasig.org/browse/CAS-975

So I think that upgrade on v3.4.9 of CAS solves the issue.

Here we just upgraded our inspekt libraries (jar) :
1.0.2.GA -> 1.0.4.GA

And now CAS answers correctly an usually cas:authenticationFailure in XML (with HTTP status code 200)

And now SOGo forwards correctly the user to the CAS authentication form.
vbonamy

vbonamy

2013-10-23 10:07

reporter   ~0006162

-> the prioriry and severity of this issue can be lower now ; because the cas server must not respond with an Error 500 ...

Issue History

Date Modified Username Field Change
2013-10-22 19:14 vbonamy New Issue
2013-10-23 10:03 vbonamy Note Added: 0006161
2013-10-23 10:07 vbonamy Note Added: 0006162
2013-10-23 13:12 ludovic Assigned To => jraby
2013-10-23 13:12 ludovic Status new => assigned
2013-10-23 13:13 ludovic Severity major => minor