{"id":122,"date":"2004-04-12T16:43:54","date_gmt":"2004-04-12T22:43:54","guid":{"rendered":"http:\/\/www.mooreds.com\/wordpress\/?p=122"},"modified":"2004-04-12T16:43:54","modified_gmt":"2004-04-12T22:43:54","slug":"is-transparent-access-control-worth-unintelligible-error-messages","status":"publish","type":"post","link":"https:\/\/www.mooreds.com\/wordpress\/archives\/122","title":{"rendered":"Is transparent access control worth unintelligible error messages?"},"content":{"rendered":"

Partly egged on by Rob<\/a> and Brian<\/a>, I just took a long overdue look at container managed security for web applications.<\/p>\n

My conclusion: it’s nice, but there is one major flaw that dooms the whole premise. Users expect informative error messages when they ‘sign in’ and there’s no way to do that with container managed security.<\/p>\n

I was using Tomcat 4.1, which is to say, I was examining the servlet 2.3 specification. (I just looked at the 2.4 specification and can see no amelioration of the above issue.) I also focused on the FORM method of authentication, as that’s the most customizable. (I imagine, for an intranet app obsessed with security, client certificates would be an worthwhile avenue of investigation.) I found the servlet specs<\/a> to be very helpful in this process. <\/p>\n

With the FORM method of authentication, you can customize the appearance of your login and error pages, to some extent. This is a huge win. <\/p>\n

I really liked the automatic access control–no checking at the beginning of every ActionForm or JSP for any specific attribute. Additionally, you can protect different URL patterns easily, and for most of the applications I write, this is enough. If you need to protect buttons on a page, you can always resort to isUserInRole<\/a>.<\/p>\n

Also, you can protect the login and error pages, which should never be accessed directly<\/a> in a separate \/safe directory, to which you can prohibit all access. <\/p>\n

For the times when the user is denied access to a resource, you you can create a custom 403 error page, using the error-page<\/a> directive in web.xml. Unfortunately, you only seem to get three attributes: javax.servlet.error.message<\/code>, javax.servlet.error.request_uri<\/code> and javax.servlet.error.status_code<\/code>, which limits the nature of your response. These were what Tomcat gave me–I don’t think it’s part of the spec. Regardless, IE, with default settings, doesn’t display any custom error messages<\/a>, which makes this a rather moot point for general webapps. <\/p>\n

Creating a logout page is fairly easy, just call session.invalidate()<\/code> (though there seem to be some non standard<\/a> methods of doing it as well).<\/p>\n

However, as mentioned above, I just don’t think that users will accept the generic login error messages that you are forced to give. For instance, you can’t tell whether a user didn’t enter a password, or entered an incorrect password. You can’t redirect them back to a login page with helpful error messages around the incorrect box. These are fundamental issues with authentication–no serious webapp simply throws up its hands when a user doesn’t login correctly the *first* time. <\/p>\n

Separate from user experience, but still related to authentication behavior, you can’t ‘lock out’ users who’ve attempted to login too many times. Sure, you can keep track of how many times they’ve tried to login, but the authentication process is out of your hands.<\/p>\n

Additionally, the fact that you’re tied to a particular implementation for user\/role definition means that writing custom authentication code that just accesses a RDMBS is actually more portable. <\/p>\n

The answer, to the question posed in the title of this post: “is transparent access control worth unintelligible error messages?”, is almost always “no.” And folks accuse developers of not having any sense of user interface!<\/p>\n","protected":false},"excerpt":{"rendered":"

Partly egged on by Rob and Brian, I just took a long overdue look at container managed security for web applications. My conclusion: it’s nice, but there is one major […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,6],"tags":[],"class_list":["post-122","post","type-post","status-publish","format-standard","hentry","category-java","category-programming"],"_links":{"self":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/122","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/comments?post=122"}],"version-history":[{"count":0,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/posts\/122\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/media?parent=122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/categories?post=122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mooreds.com\/wordpress\/wp-json\/wp\/v2\/tags?post=122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}