> I have been working on integrating webmail with our uPortal instance. > We plan to use a PHP web client and PAM CAS. To display recent email > inside the portal I am implementing a recent email servlet against our > IMAP server like Yale's RecentEmail channel.
I think there's even a special portlet for IMAP and CAS inside uPortal. (I'm not sure though because we're not using uPortal at our univ) > For the PHP webmail client we intend to install IMAPProxy to allow > IMAP connection pooling. This means the PHP webmail client will have > to be configured to attempt to re-use CAS proxy tickets. That will most likely not require any changes to the webmail as it is the default behaviour of a webmail client to try again with the same password. http://wiki.horde.org/CASAuthHowTo The information on that page is already obsolete though. Our system will go live this week for well over 20k users. It's using horde3.1.1 and a patched ESUP PHPCAS v4.22-RC1. I'll update the documentation to the final version somewhere tomorrow. > The PHP webmail/IMAP proxy configuration is pretty much decided but > for the servlet I was thinking it would also be a good idea to attempt > to re-use IMAP connections. I can see two ways to do this. > > # Method One > > Use IMAPProxy server software and allow the servlet to access cached > CAS proxy tickets. I was thinking of using WhirlyCache (or something > similar) to cache the proxy tickets in memory. The main advantage of > this is that it is easy to implement. However, it will heavily depend > on the IMAPProxy. It may also result in extra unnecessary load on the > IMAP server due multiple connection attempts made due to stale CAS > proxy ticket credentials. We have worked out a similar approach for -again- well over 20k users (it's running in a BlackBoard portal). You don't need the WhirlyCache as receipts and tickets can be cached in session easily. I guess there will be even less load than before on the IMAP server because you probably didn't cache any connections before. The stale proxy tickets will definitely give some extra load, but we haven't seen any problems with that yet in the test setup. [ask again in a few weeks...] > # Method Two > > Use WhirlyCache again but this time bypass IMAPProxy and actually > cache IMAPStore objects in memory. In this technique the Java code is > acting as the IMAP proxy. Storing IMAPStore objects is likely to > require more memory resources but I am hoping it will remove the need > for the attempt, fail and retry sequence of events. Please let us know your findings if you test this setup. I'm very interested in hearing your findings about this. -- Velpi _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
