and now want to use a declarative means of restricting access to resources based on user roles. It seems to me that the primitive URL patterns defined by the Servlet spec (EXACT, PATH, EXTENSION, DEFAULT) is not sufficient in my case, since I have requests of the form:
I don't believe anyone has done this, primarily because it would break compatibility with the servlet specification. sf uses PCRE's internally, so it should not be hard to add general regular expression capabilities to the URL matching code. Note that the next major version of sf is basically being re-written from scratch, along with the pattern-matching code. This will give me the opportunity to (possibly) add features like this with greater ease (and that your modifications will likely be incompatible). If you want to add regex matching to sf, you're definitely going to have to recompile sf, though.
Note that a URL pattern of "*edit" would work already if you wanted only admins to be able to edit things.
-chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Marvelous! I looked more carefully on how the pattern matching is implemented in the library, and discovered that asterisks are taken as wildcards in EXACT patterns (contrary to the spec?), which is just what I need!
/Mats
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Me again,
Has someone already tried to extend the library to support regular expressions as URL patterns for authorization?
I have adopted the following |best practice for URLs:
http://microformats.org/wiki/rest/urls
and now want to use a declarative means of restricting access to resources based on user roles. It seems to me that the primitive URL patterns defined by the Servlet spec (EXACT, PATH, EXTENSION, DEFAULT) is not sufficient in my case, since I have requests of the form:
GET http://example.com/objects/4982/edit
which should only be accessible to users in the Admin role.
Grateful for any ideas!
Mats
Mats,
I don't believe anyone has done this, primarily because it would break compatibility with the servlet specification. sf uses PCRE's internally, so it should not be hard to add general regular expression capabilities to the URL matching code. Note that the next major version of sf is basically being re-written from scratch, along with the pattern-matching code. This will give me the opportunity to (possibly) add features like this with greater ease (and that your modifications will likely be incompatible). If you want to add regex matching to sf, you're definitely going to have to recompile sf, though.
Note that a URL pattern of "*edit" would work already if you wanted only admins to be able to edit things.
-chris
Chris,
Marvelous! I looked more carefully on how the pattern matching is implemented in the library, and discovered that asterisks are taken as wildcards in EXACT patterns (contrary to the spec?), which is just what I need!
/Mats