WebLogic session.invalidate() is not enough

Implementing correctly security in WebLogic can be a daunting task. So many caveats and dodgy behaviors and not all is CLEARLY documented.

Suppose I have protested all my JSP with this clause in web.xml:

  <security-constraint>
        <web-resource-collection>
            <web-resource-name>AdminPages</web-resource-name>
            <description>
                These pages are only accessible by authorized
                 administrators.
            </description>
            <url-pattern>/*.jsp</url-pattern>
            <http-method>GET</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>
                These are the roles who have access.
            </description>
            <role-name>
                admin
            </role-name>
        </auth-constraint>
        <user-data-constraint>
            <description>
                This is how the user data must be transmitted.
            </description>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
 <error-page>

and the role "admin" is defined in a weblogic.xml:

     <security-role-assignment>
         <role-name>admin</role-name>
         <principal-name>Administrators</principal-name>
         <principal-name>Monitors</principal-name>
         <principal-name>Deployers</principal-name>
     </security-role-assignment>

At this point all your JSP require that you are authenticated.

To logout, you can provide this JSP code:

<% 
session.removeAttribute("User");
session.invalidate(); 
weblogic.servlet.security.ServletAuthentication.invalidateAll(request);
request.logout();  // only from WebLogic 12, requires Servlet 3.0
%>

Without the "invalidateAll(...)", it will not work. Apparently the session information is still kept on the server, and the session will be immediately resumed without asking you to authenticate again. Frustrating. Documentation on this topic is a bit confusing.

OSB, Multipart Email and reading attachments in IPad

How to send an email with attachment in OSB is already covered elsewhere.

However there are some caveats: some email clients like IPad/IPhone are really picky, and they don't handle correctly a PDF in attachment if the OSB default is used.

Here it says: OSB when an attachment is present in the message, OSB is overrding the "Content-Type" property to "multipart/related" inspite of me setting the "Content-Type" property of HTTP Transport Header in OSB

The problem is that an IPad seems to handle correctly only messages with "Content-Type" = multipart/alternative or multipart/mixed. So the only choice is to manufacture yourself the $body message to send to the SMTP Mail Business Service, by hardcoding the multipart/alternative. By no means you should have Content-ID around: IPad doesn't like them.

This is done in an Oracle Support article : Service Bus 11g: How to Send a Multipart Email (Doc ID 1561677.1)

To import the project in a OSB version prior to 11.1.1.6, in ExportInfo, change : imp:property name="productversion" value="11.1.1.5" and rejar everything.

Refer to http://en.wikipedia.org/wiki/MIME for comprehensive explanation of MIME standards.

Gmail menu "show original" was essential to debug the actual email content.

See also this article where Apple support warns about possible issues with attachment... guys, how about testing better your code and make it more robust?

Also, always remember to delete $attachments variable before you route to BS !

One more thing: it seems that iOS changes the filename into filename="mime-attachment.pdf" for large PDF ( > 50 KB approximately). This is really really weird. no workaround so far. Not a HUGE issue, but still annoying. Actually this seems to happen only if there is a space in the filename...

Stormy weather...

This huge secular tree - along with many, many others - was uprooted on Friday by a freaky storm over the Lausanne lake.

People here assure they have never seen anything like that before.

A gym colleague working in the insurance industry tells me that in the last 5 years these extreme weather events are becoming so frequent and unpredictable that the insurance industry is unable to handle this kind of business any longer, because forecasts are irremediably too optimistic and reality is always a lot worse.

All this spells "we are screwed"... and more than us, our children are screwed and - if anybody is still fool enough to put someone in this collapsing world - our grandchildren too are super-screwed.