Monday, September 8th, 2008
Form access control via jQuery and Jaxer
Category: Aptana
Tom Kirkpatrick has written about writing one form, and using access control to map it to various roles using jQuery and Jaxer.
This is a simple pattern. You never want to use client code to manage access, for obvious reasons. The approach is to use the server to spew out HTML that makes sense, and then parse in the input and check access control.
Using Jaxer, this is all taken care of in JavaScript, and you can use libraries such as jQuery to do work there.
One solution to the roles issue is to manipulate the DOM on the server before it heads to the client. The magic lies in the 'server-nocache' directive which tells Jaxer than "the code should only run on the server, and that the code or should not be cached and will therefore not be available during callbacks."
-
-
<script runat="server-nocache">
-
-
// some kind of authentication to get current users role
-
role = getRole()
-
-
// remove private form elements
-
$((role == 'employer') ? '.employee.private' : '.employer.private')
-
.remove();
-
-
// disable irrelevant form elements
-
$((role == 'employer') ? '.employee input' : '.employer input')
-
.attr('disabled', 'disabled');
-
-
// no need to inject Jaxer client framework (saves about 20k)
-
Jaxer.response.setClientFramework();
-
</script>
-
Of course, to be safe, you need to always test access control incoming, and not rely on the HTML that you send down.
Related Content:
runat=”server-nocache” … never seen that before.
It’s a great example but it doesn’t need the “server-nocache” at all: caching is only for functions, and there aren’t any here, so nothing would get cached, and nothing would be available for callbacks ;-). That was already corrected in his original post.
Sorry, to be more clear: it needs “server”, and while you could use “server-nocache just as well in this case since they do the same thing in the absence of functions, that would be 8 redundant characters…