1. It allows you to present your users a nice message rather than the ugly, server-generated default page.
2. It serves to mask the server’s identity – so, security is a little better.

The first point is obvious. But the second point may need some clarification – why do we care about the server’s identity?
The reason is – when a potential attacker knows which server your application is running on, they can try specifically crafted attacks that take advantage of the specific system’s vulnerabilities.

If you do not configure Glassfish is especially bad in terms of the second point, since it displays a big message saying “I am glassfish!” when the user tries to access a page that does not exist.
Now, you may think – why is that bad?
Well, there are a few Glassfish vulnerabilities out there. Have a look at these, for example:

1. XSS vulnerability in the admin console
2. SSL Man In the Middle attack vector

Convinced?
Well.. how about setting custom error pages? So – instead of getting something like this:

which tells the world what application server you’re using, you get your own error page?

This is quite easy to do. The error pages configuration is found inside domain.xml and you can either edit it manually or use asadmin on the command line.

To edit domain.xml manually, open the file. It should be in your application server’s home directory, under your domain’s config folder. So something like

Inside, find the part describing your server. It should resemble the following:

Inside, the virtual-server element, you can add properties for your error pages. You need to provide the path to the page you want displayed, the reason code, and a name, like so:

The name is just a unique name. If you need to add more error pages – just increase the number with each one.
The value attribute contains three parameters: the path to the HTML page you want to display when this error occurs, the reason, and the error code.
Based on the error code you provide, Glassfish knows which page to display.

The path to the error page is relative to your domain’s config folder. In the example above, I want Glassfish to serve a 404.html page that’s found inside the war file of an application deployed to this domain. You can, however, point it anywhere.

To configure other error pages (e.g. HTTP502 or HTTP503 – just add another property (remember to change the name attribute though).

Configure application specific error page

The above configuration works well for a Glassfish-wide 404 error page. This is good as a fallback plan, and is probably what you want displayed when the user got the context wrong.
So, for example, let’s say your application is deployed to http://example.com/app1. The user entered http://example.com/app. In this case, Glassfish’s 404 page will be displayed, and if you configured it as above – it will not offer information about your server.

However, you might want a different page to be served if the user tried to navigate to a bad URL, but got the context right. So, let’s say that you have the following page in your application: http://example.com/app1/win.xhtml.
The user, somehow, managed to try and get http://example.com/app1/wins.xhtml – which is not valid in your application.
The configuration above would take care of it, but if you want a specific 404 page for your application, you can still do it – by using your application’s web.xml:

The location is relative to your application’s web root.
The configurations in the web.xml snippet above and the domain.xml before – point to the same page, but they can point to different locations, thereby allowing you to have an application-specific error page, and a site-wide fallback one as well.

1. Secure flag
2. HttpOnly flag
3. Post-login session key regeneration

The cookie’s Secure flag

The secure flag is telling the browser to only send this cookie over secure (SSL) channels. This is irrelevant if your application is not SSL-secured (but penetration testing is rarely done on these anyway).
There’s no way for Seam to automatically know whether your application is deployed on an SSL-protected server or not. Therefore you need to take care of it yourself.
Normally, you would configure this in the container’s configuration, but this isn’t always possible, as not all containers support this, especially if your container does not use Servlet 3.0 specification.
The Servlet Filter below adds the secure flag to your cookie, and does it smartly by checking first to see if you are using a secure connection. This is good for applications that may be deployed either way (e.g. when your development environment isn’t SSL-protected).

The cookie’s HttpOnly flag

Setting the HttpOnly flag on a cookie helps protect against some forms of attacks related to cookie stealing. This flag was introduced by (surprise surprise!) Microsoft with Internet Explorer 6, to prevent a vulnerability where an attacker could access your cookies directly, using Javascript, and send them over to their website.
This recommendation is a favourite with security consultants, and you’re bound to have that raised if you don’t set the flag on your cookies. I personally believe that it’s a low priority issue (see here for a short discussion) – but it’s quite easy to do, so why not.
Again, this setting should really be performed in the container, but if it doesn’t support Servlet 3.0 you may have to revert to using the Servlet Filter.

Post-login session key regeneration

This is quite a good one. See, when the user first lands on your website, your Seam application (via the container) sets a cookie on their computer, with a JSESSIONID parameter. This is the session id all JEE containers use to track user sessions in the cookie.
By default, after the user logs in successfully, this session id remains the same. Hence, if an attacker can get hold of this session id – they can then create a cookie on their computer that has the same session id, and use it as an authenticated user. This attack is called session fixation.
Obviously, this is not a very good vulnerability to have in your website, and the Servlet Filter below takes care of it by regenerating the session id after a successful login.

The Servlet Filter

In Seam, it is very easy to add a Servlet Filter to your application without touching any xml. In essence, the filter becomes a Seam component.
You can do everything using Seam’s annotations like so:

The two important annotations here are the @BypassInterceptors – which tells Seam to not apply any of its interceptors to this component. This is important because the Servelt Filter is sort of a pseudo-component that acts like an interceptor itself.
The second important annotation is the @Filter – telling Seam where this filter needs to go in the filter chain. For this filter, the right place is within Seam’s rewriteFilter, because the main action here entails rewriting the HTTP response.

The only method we need to override on the AbstractFilter is the doFilter() method. This method takes a ServletRequest and a ServletResponse objects, together with the FilterChain.
The request and response objects are the actual request the user’s browser submitted, and the response it is going to receive. The FilterChain is the chain of filters configured for the application – of which the CookieFilter is a member.
It is important to link back the chain at the end of the doFilter method, otherwise it will not be completed.

The first part of doFilter() below tests whether the response object contains the “SET-COOKIE” header. We do not want the application to send a new cookie with every request made of the server, so we only let the servlet filter piggy-back on responses that already have this flag set.
Now, because the cookie is sent as a header on the response object, we can’t just add the HttpOnly and secure to it – we need to recreate the cookie header completely.
The code excerpt below does just that by retrieving the session id (the JSESSIONID attribute), and the context path from the existing header.
It then tests to see whether the connection is secure (using the isSecure() method on the request object) – and sets the flag accordingly.

Finally, the code re-sets the “SET-COOKIE” header, using all the existing content, and adding the HttpOnly flag, and also the secure flag if required.

To generate a new session-id after a successful login attempt, we are going to use a little flag of our own. On our web application, the first request will have the ‘SET-COOKIE’ header, but subsequent requests will not.
We use this knowledge to find the first post-login request that goes to a page (and not, say, an image) – this is done by testing the query string, which in a Seam application must not be null (because it will have the cid= attribute on it).
We also test for the presence of POST_LOGON_ATTR – an attribute we are going to manually add to the session after we change the session id. This will ensure that we don’t create a new session id on each new request.

When the first post-logon request on a session hits this filter, the if statement below returns ‘true’. The filter then needs to invalidate the session and create a new one (thereby generating a new JSESSIONID).
However, the filter must make sure that the new session retains all the information from the old one. Therefore, before invalidating the session, it saves a map of all the session attributes, and copies them over to the new one.

This is it! your filter is now fully configured as a Seam component, and will work on your request. You can use Firefox’s View Cookies extension to verify that your JSESSIONID changes post login, and that the HttpOnly and secure flags are added to the cookie.

Below is the full Servlet Filter class, including the import statements.

What’s a timing attack?

A timing attack is when an attacker guesses your hashed password character by character, as opposed to using a dictionary or anything similar to try a brute force attack.

The way systems work is that your application hashes the password it receives from the user, and matches it to the hash it stores for this user in the users table.

This comparison stops at the first non-matching character. Therefore, it is possible to find your hashed value character by character, because the more correct characters you get – the longer the function takes to return. At least in theory.

What’s an incremental cracker brute force attack?

In an incremental crackin brute force attack, the attacker uses an incremental password cracker (e.g. John the Ripper) to feed your system a huge number of passwords – until it finds a good one.
While you may think that this takes time and effort – in reality these things rely on how responsive your web server is – so the faster your login code returns – the faster these tools will crack your user’s password (given a username, of course).

To this end, it makes sense to make your hashing algorithm as non-optimized as possible. This is nothing new, and has been out there for over a decade (look up ‘adaptive hashing’) but – most of these hashing algorithms, while they take their time – are at least consistent in the sense that they return their result consistently as well – therefore still rendering your system vulnerable to timing attacks.

The solution

The solution is only 2 lines added to the security.php file under cake/libs:

The two lines above introduce a random wait time into your hash function.
line (1) generates a random number. The mt_rand function returns a number that can be quite large. Therefore, the usleep() method in line (2) uses its modulo 1,000,000 value, and multiplies it by 3, to introduce a sleep time of 0..almost 3 seconds. Since this is a pseudo-random number, it plays hide and seek with any timing-attack algorithm, but also delays incremental crackers enough to send them elsewhere.

The impact on your users should be minimal. They shouldn’t log on or log off more than once a session, and a mean time to wait of just over 1.5 seconds is not too bad in these scenarios.

Good luck!

But, I was wrong.

For starters, the timeout= attribute does not take an EL expression. You can only have a numeric value there. So much for setting it dynamically.
The other thing is – we never start conversations manually – only with pages.xml directives. And I really didn’t want to change the entire conversation management, or dig into Seam code for that matter.

Some google-searches later and I found the HTTP session listener.

The HTTP session listener is a small class you can configure in web.xml, that captures session creation. It has two methods:

sessionCreated() is called when a new session is created. All that’s left is setting the required timeout there:

This is all very nice when you know the session timeout – but if you know it in advance – what’s the use of adding this listener? Just configure components.xml and be done with it.

Getting the timeout configuration value from a database

In our application we have an ApplicationParameterService Seam component. It exposes a method to fetch a configuration value from the database’s configuration table. Sweet. Let’s use it in the session listener:

So – in the listener, I ask Seam for the application parameter service, look up the session timeout value, which I get in minutes, and set it (transposed into seconds) on the session. No sweat.

Ah, but a little sweat.
Seam throws an IllegalStateException – No application context. This is a weired Seam phenomenon, where even though the application is running (and in fact, the login page uses the ApplicationParameterService) – there’s no active context at the time that the listener is called.

This can be solved by forcing an application context if there is none:

and that’s it.

To have the listener capture session creation – you need to add it to web.xml. Make sure you keep Seam’s listener as the first one in the listeners list though. Seam needs it this way:

Examining the request (in firebug or Apache access log) shows:

In firebug, you can also see the referer:

As you can clearly see (click on the image to see clearly…) – the referer of the GET request is the jquery.gritter.css file. This is strange right?

Well, css files can definitely issue GET requests. For example, they may try to load background images. This calls for a quick look into the css file itself:

This tries to set a background image on the wrapper div, so that it can solve a nasty IE7/8 positioning bug. However, this results in a GET request to the current directory – which happens to be the css directory. Naturally – this does not end well.

Luckily, the fix is easy. All you have to do is add a real background image. As long as you make it 1px by 1px (or completely transparent) – you’ll be fine and the 404′s will disappear:

Look at your logs/firebug – all good now!

There are many things that contribute to the rise or fall of your website. Anyone, and Google especially, will tell you that content is king. You have to have good, original content. Your site needs to be original, provide good value for your users, etc etc.

But there are always those small things that can make or break it for you.

Design is one of these things.

A good design can make or break you. It’s a fact. Websites can no longer live on content alone. It has to look nice, and it has to feel good. Human beings are aesthetic creatures. We like things to look good, and if your website looks bad – well – your users are going to go somewhere else.

I won’t focus on badly designed websites. The nature of the Internet is that designs change, and sites I may link to here today may no longer look like this in the future. If you want to have a look at some bad design examples, go over to the webpages that suck website and have a look around.

I want to talk about typography.

Typography is fashion

Like everything else about website design (and really, any design at all) – typography is a matter of fashion. It changes, morphes and is being reborned every few months.

Think about webpages from the nineties: default fonts (or worse – Comic Sans), default spacing, awful colors – you get the drift. Reading the web was just not a happy activity.

But design changes. With the emergence of Web 2.0 – we got a lot of white space. Websites today are more airy – there’s a lot of empty space, that brings the actual content to the front. Be it images, blocks of text, or videos – they stand out, because there’s so much white (or other non-obtrusive background color) around them.

When your text stands-out on the merit of it being the black spot in all this white – you don’t need to draw a lot of attention to it based on font, loud colors and size. That being so, designers started making the fonts blend in more with the general background. White background received grayish texts, with large line-spacing, and all was well.

Additionally, we started using larger text size to draw attention to specific parts of the page. The slogan, the mission statement, etc. (See picapp for example)

Websites started using texts as logos, and even when these are images – you still read them.

The font stack

It was only a matter of time until a common font-stack started appearing in all websites. In 2008-2009 many websites switched to the Lucida stack :

However, today (mid-2010) we see more and websites go to the Helvetica and Arial option, which I personally find better on the eyes. Also, and that’s a very important consideration when you’re trying to create an authoritative or business website – fonts have feelings.
That font feeling

It sounds a little silly, I admit, but think about it. Fonts have feelings attached to them. Even if you don’t sense it upfront – it’s there. Have a look at the following fonts, see what you make of them:

I am a very respectable website. I am an authoritative source of information about all things electronics. The writers here know everything there is to know about the gadgets they are reviewing. Really, you don’t need to look anywhere else – read it all here, and buy from me!

What did you feel about this text? Did it convince you? How about if it looked like this?

I am a very respectable website. I am an authoritative source of information about all things electronics. The writers here know everything there is to know about the gadgets they are reviewing. Really, you don’t need to look anywhere else – read it all here, and buy from me!

Ok, so the second example is maybe pushing it a bit too far, but the point I am trying to make, is that some fonts just don’t come across as serious enough. The Lucida stack, or the Comic Sans MS fonts give your users a feeling of reading a childrens book – not a serious website.
For some readers (and you may be one of them) – this feeling is very subtle, but it is there.

Another issue with these fonts is that they are a bit more difficult to read, compared to other fonts. Try reading a long text in any of the Lucida family and you’ll see what I mean. The spacing between the letters, and the ‘not quite there’ shape of each individual letter makes your eyes and brain work more. I would suggest not to use these fonts for long articles…

Let’s try this one:

I am a very respectable website. I am an authoritative source of information about all things electronics. The writers here know everything there is to know about the gadgets they are reviewing. Really, you don’t need to look anywhere else – read it all here, and buy from me!

See? already better.

So fonts have feelings. In the sense that they stir specific feelings in readers. You need to make sure you find the right fonr for your content. Ask yourself:

• What are you trying to achieve?
• What is your goal?
• How do you want users to feel towards your content?
• How long do you want them to spend on your site?

Typography, along with space, multimedia and colors, makes your website appeal or repel. Yes, it’s “just text” – but most of the websites out there are about text. Don’t punish your users – go easily on their eyes.
A final word – why is font choice so very important:

It would be nice if you could offer your users the option to automatically change the text color your website, and is very easy to do with Jquery.

To start, make sure to download jQuery and have it accessible. As an alternative, you can link to it from a CDN (e.g. http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js).

I’m going to use just an index.html file for the simple demo. Ensure the jquery .js file is accessible by your page, and you are good to go:

This is not the full thing. It is just the header. What you create here is a strip of small boxes in different shades of gray to black – like in the demo page.

Our goal is that when a user clicks on a colored div – the text changes color to the shade that was clicked. This can be really neat!

To add the magic, we’ll add a simple jQuery to capture a click:

Changing the color is easy. When a color <div> is clicked, the browser executes the code found in the click() callback we just added.

All the function does is find the background color of the clicked div and set it as the text color on the main div.

You can test this for yourself on the demo page.

I refresh and it’s gone..

After your user changes the color, he may refresh the page, or go to another link on your website. When this happens – the color is reset to normal. This is not so good.

Luckily, we have cookies. Using a cookie we can save the user’s color preference:
(thanks to dynamicdrive for the cookie scripts)

The functions above just set and get a value on a cookie.
To use them, change the previous code a little bit:

All that’s left is add some text in the main div and test:
(Below is the full file I use)

But wait, there’s another option:

And now – with any color!

This second demo tells it all.
I am using the excellent colorPicker plugin to do it.

To implement:
1. Download the plugin’s js files, css and images. The only js file you really need is colorpicker.js – so you can disregard the rest of them. (Naturally, you need jquery.js – but we took care of it already in the previous example)
2. Put the css files nicely somewhere (have a look at the source code in the demo to see. I basically put css files under /css/ and images under /images/)
3. Copy these two styles to your style element, and remove the style for div.color-box.

Add the colorpicker plugin and its main css to your element:

Change the top part of your index.html page to only show the color picker div and not the series of gray div elements:

Now add the following javascript down the bottom (replace the $(document).ready() function with this one) :

That’s it really enjoy…

You code, fire up the browser and -

the images are all wrong! They are too large, your page looks awful, or you get sliders all over the place. Not happy at all.


This is even worse when you don’t control the images. Say you have to hotlink from somewhere, e.g. Amazon. What are you going to do?

Well – here we go, rsz helper to the rescue!

The helper is simple. I coded two methods, but of course you can extend it whichever way you want.

The first method receives the image url, and the maximum dimensions (width and height) it can take on your screen. The helper finds the actual dimensions of the image, calculates the new height and width – according to the maximum dimensions you pass in – and returns an array with the new dimensions. The new dimensions keep the aspect ratio of the image so it doesn’t appear distorted.
You can later use this array to output the image on your website:

The code above resizes any image to the right dimensions. It returns an array with the new width and height. You can use this is your view as follows:

The image will be displayed in its new size: 152x100px.

You can change the helper to output the img tag directly, making your views cleaner, and allowing less space for copy/paste mistakes:

and in your view:

The problem with this method

The problem with this method is that you actually load the image twice. The helper loads the image on the server side (with getimageresize), and the client’s browser loads it on the client side. This is a bit wasteful and can make your pages load slower.

There are a few ways to overcome this, but it depends on the way you store your data. In my application, for example, I constantly retrieve new images, but once I load them, I store them in a table containing the image’s url, size and width.

The first time I load an image, I use getimagesize() to find its dimensions. I then store them in the table, and the next calls to the helper’s imgresize method do not need to visit the image’s url at all:

In this very simple case, getimagesize is called only if the image’s dimensions are null. Depending on your application, this method can be extended to either receive an Image model and update it, or to return more values if this is the first time it is called.

See an image resizer demo on Choozza.com

• Subscribe to the comments for this post?
• Share this on del.icio.us
• Digg this!
• Post this on Diigo
• Add this to DZone
• Post on Google Buzz
• Add this to Mister Wong
• Share this on Mixx
• Share this on Reddit
• Stumble upon something good? Share it on StumbleUpon
• Share this on Technorati
• Tweet This!

]]> http://duckranger.com/2010/06/resize-images-on-the-fly-with-cakephp/feed/ 0 http://duckranger.com/2010/05/cakes-security-component-timeout-problem/ http://duckranger.com/2010/05/cakes-security-component-timeout-problem/#comments Wed, 26 May 2010 05:56:16 +0000 Duck Ranger http://duckranger.com/?p=280 CakePHP’s security component is awesome. I use it all the time for its CSRF protection (Which will be the subject of a future post).

But sometimes, it does not work as expected. Frustration ensues.

In one of my projects, I have a form with a few text areas on it. The user uses this form to create or edit a story. After adding the security component to the controller, I noticed that when the user submits the form they get blackholed, and the story was not saved. With users pouring their hearts into the stories, this is really bad.

This behaviour seemed strange, to say the least.

The first thing I did was look for the session timing out on me. In core.php I have the following:

Configure::write('Security.level', 'high');
Configure::write('Session.timeout', '120');

based on Cake’s configuration, these should set the session timeout to 20 minutes (120 multiplied by 10). This may be a little too short for writing stories, so I raised the timeout value to 240 – resulting in 40 minutes, which is definitely enough. The stories are not THAT long.

However, this did not change the system’s behaviour. It almost seemed like the session times out long before the 40 minutes passed.

Enter Security component

When I removed the Security component from the controller, all was working great. It was time to delve into the code.

So, how does this security component work, anyway?

When you use the security component, Cake generates your forms differently.

Notice: In order for the security component to work correctly, you must use the form helper to create all of the fields on the form, as well as creating the form with $form->create() and closing it with $form->end().

Consider this in the view:

<?php
    //add.ctp

    echo $form->create('Story', array('target'=> '_parent') );
    echo $form->input('title' , array('label' => false));
    echo $form->input('excerpt', array('rows' => '20',  'cols' => '80', 'label'=> false));
    echo $form->input('body', array('rows' => '20',  'cols' => '80', 'label'=> false));
    echo $form->input('notes', array('rows' => '20',  'cols' => '80', 'label'=> false));
    echo $form->end(array('name' => 'save'));  
?>

When the security component is not activated, the resulting form looks like this:

<form target="_parent" id="StoryAddForm" method="post" action="/stories/add">
    <fieldset style="display:none;">
        <input type="hidden" name="_method" value="POST" />
    </fieldset>
    <div class="input text">
        <input name="data[Story][title]" type="text" value="" id="StoryTitle" />
    </div>
    <div class="input text">
        <textarea name="data[Story][excerpt]" cols="80" rows="20" id="StoryExcerpt" ></textarea>
    </div>
    <div class="input text">
        <textarea name="data[Story][body]" cols="80" rows="20" id="StoryBody" ></textarea>
    </div>
    <div class="input text">
        <textarea name="data[Story][notes]" cols="80" rows="20" id="StoryNotes" ></textarea>
    </div>
    <div class="submit">
        <input type="submit" name="save" value="Submit" />
    </div>
</form>

As you can see, this is just a simple html form.
To have the security component work its magic, you add it to the uses array in the controller:

//stories_controller.php
    var $components = array('Security','Auth','RequestHandler');

With the Security component activated this way, the form is generated with a few extra fields:

<form target="_parent" id="StoryAddForm" method="post" action="/stories/add">
    <fieldset style="display:none;">
        <input type="hidden" name="_method" value="POST" />
        <input type="hidden" name="data[_Token][key]" value="5a364d27f9e39686bb6032ceed0a4ebcc1abba8e" id="Token1821306795" />
    </fieldset>
    <div class="input text">
        <input name="data[Story][title]" type="text" value="" id="StoryTitle" />
    </div>
    <div class="input text">
        <textarea name="data[Story][excerpt]" cols="80" rows="20" id="StoryExcerpt" ></textarea>
    </div>
    <div class="input text">
        <textarea name="data[Story][body]" cols="80" rows="20" id="StoryBody" ></textarea>
    </div>
    <div class="input text">
        <textarea name="data[Story][notes]" cols="80" rows="20" id="StoryNotes" ></textarea>
    </div>
    <div class="submit">
        <input type="submit" name="save" value="Submit" />
    </div>
    <fieldset style="display:none;">
        <input type="hidden" name="data[_Token][fields]" value="6e6401136c6c253e621550b05eaefa112da437c2%3An%3A0%3A%7B%7D" id="TokenFields1859539122" />
    </fieldset>
</form>

Assuming you used the $form helper to generate the form and all its fields, the Security component adds two more hidden fields to it:

data[_Token][key] – this is a token that marks this form as generated using the Security component. The token is unique to each form, and when the user submits the form back, Security component verifies that the token is valid. This is to ensure that the form originated from your website, and prevents attackers from crafting similar forms themselves and submitting them to your application.

data[_Token][fields] is a hash of all the fields created using the $form helper. When the form is submitted a valid key, Security component also validates that the hash matches. This way, if an attacker managed to get a valid token, they can’t add fields to the form that weren’t there to begin with.

(Note: it is possible to instruct the Security component to disregard specific form-fields when generating and validating the data[_Token][fields] hash. You can do it in your beforeFilter() method by using the $this->Security->disabledFields array).

Blackholing Requests

If either the key or hash submitted with the form is invalid (or missing altogether), the form submit request will be blackholed. This will usually result in your users getting a blank page, and the data not saved anywhere. Obviously, this was happening to my stories, but why?

The token was valid, because I got it from the Security component to begin with. The hash was valid, as I never tempered with the form. All the signs pointed to a timeout…

Your token has a time to live as well!

Diving into Cake’s Security component code, I found the following:

//in cake/libs/controller/components/security.php
..
function _generateToken(&$controller) {
    ...
    $authKey = Security::generateAuthKey();
    $expires = strtotime('+' . Security::inactiveMins() . ' minutes');
    $token = array(
        'key' => $authKey,
        'expires' => $expires,
        'allowedControllers' => $this->allowedControllers,
        'allowedActions' => $this->allowedActions,
        'disabledFields' => $this->disabledFields
    );
    ...

So, when a token is generated, it gets an expiration period. Mmm… so let’s have a look at the inactiveMins() method.

// in cake/libs/security.php
..
function inactiveMins() {
    $_this =& Security::getInstance();
    switch (Configure::read('Security.level')) {
        case 'high':
            return 10;
            break;
        case 'medium':
            return 100;
            break;
        case 'low':
        default:
            return 300;
            break;
    }
}
..

See what happens here? Regardless of the timeout you configure for your sessions, the token expiry time relies only on your Security.level settings. This means that my tokens may expire long before my session does. Which, apparently, is exactly what happens…

The way the session timeout is calculated, is that the number you set for Session.timeout in core.php is multiplied by a number depending on your Security.level setting.
For Security.level = high, this number is 10.
For Security.level = medium, this number is 100.
For Security.level = low, this number is 300.

See the correlation? Instead of returning the calculated session timeout, this method returns only part of the equation!

Now, there may be some very good reasons for that, but none of them help me when I want all the benefits of a high Security.level setting together with allowing my users ample time to write their stories.

It is time to change cake’s code!

// in cake/libs/security.php
..
function inactiveMins() {
    $_this =& Security::getInstance();
    $timeout = Configure::read('Session.timeout');
    if (!isset($timeout)) {
        $timeout = 1; // if not configured - use the original pattern
    }
    switch (Configure::read('Security.level')) {
        case 'high':
            $factor = 10 ;
            break;
        case 'medium':
            $factor = 100 ;
            break;
        case 'low':
        default:
            $factor = 300 ;
            break;
    }
    return $factor * $timeout / 60;
}

Using the piece of code above, inactiveMins(), when called, returns a number of minutes that’s equal to your session timeout. That’s it, problem solved. Security component will not blackhole my innocent users. Now, let the stories roll…

• Subscribe to the comments for this post?
• Share this on del.icio.us
• Digg this!
• Post this on Diigo
• Add this to DZone
• Post on Google Buzz
• Add this to Mister Wong
• Share this on Mixx
• Share this on Reddit
• Stumble upon something good? Share it on StumbleUpon
• Share this on Technorati
• Tweet This!

]]> http://duckranger.com/2010/05/cakes-security-component-timeout-problem/feed/ 3 http://duckranger.com/2010/05/facelets-setter-not-found-for-property-class/ http://duckranger.com/2010/05/facelets-setter-not-found-for-property-class/#comments Sat, 15 May 2010 02:33:54 +0000 Duck Ranger http://duckranger.com/?p=259 “Setter not found for property class” is one of the most frustrating errors you can get in a Seam / facelets project.

It usually appears late, and you spend a long time trying to solve it. The solution is so simple you have to bang your hand when you finally find it.

I write this in the hope that it shows first in Google searches for this error…

The stack trace

The stack trace is not very useful:

java.lang.IllegalArgumentException: Setter not found for property class
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:1594)
at javax.faces.component.UIComponentBase$AttributesMap.put(UIComponentBase.java:1499)
at com.sun.facelets.tag.jsf.ComponentRule$LiteralAttributeMetadata.applyMetadata(ComponentRule.java:49)
at com.sun.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:36)
at com.sun.facelets.tag.MetaTagHandler.setAttributes(MetaTagHandler.java:62)
at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:144)
at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:64)
at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:131)
at com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:337)
at com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:307)
at com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68)
at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
at com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
at com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:140)
at com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:113)
at com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
at com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:524)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)

The issue is actually quite simple – you used a class attribute on a non-html element. I always get it when I translate our designer’s pages to JSF:

...

See the problem? the <s:div> element actually requires a styleClass attribute, not a class.

...

• Subscribe to the comments for this post?
• Share this on del.icio.us
• Digg this!
• Post this on Diigo
• Add this to DZone
• Post on Google Buzz
• Add this to Mister Wong
• Share this on Mixx
• Share this on Reddit
• Stumble upon something good? Share it on StumbleUpon
• Share this on Technorati
• Tweet This!

]]> http://duckranger.com/2010/05/facelets-setter-not-found-for-property-class/feed/ 3