You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Simon Kitching <sk...@ops.co.at> on 2008/06/18 16:20:58 UTC
url rewriting supported?
Hi,
This email from 2006 says that "url rewriting" (ie having sessions
without cookies) is not supported by JSPWiki. Is this still true for
later releases?
http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004
Thanks,
Simon
Re: url rewriting supported?
Posted by Andrew Jaquith <an...@mac.com>.
Simon,
That makes sense. I can see why cookies aren't the best option in your
case.
As a work-around, have you considered using Prism? It won't be as
clean as tabbed browsing, but you will at least get the session
isolation you need.
Andrew
On Jun 18, 2008, at 12:22 PM, Simon Kitching <sk...@ops.co.at> wrote:
> Hi Andrew,
>
> Many thanks for the quick answer.
>
> Yes I did mean encoding the session id in the url
> ("http://host/foo.jsp;jsessionid=123?page=Main").
>
> We want to disable cookies in our dev environment so that we can log
> into the same app multiple times from the same browser; this makes
> testing some things a lot easier. Firefox shares cookies between
> windows
> unless you go to a lot of effort (setting up separate profiles). Note
> that in the setup here, there is a large existing webapp with an
> embedded jspwiki engine to serve the help pages; disabling a dev/test
> feature in order to support the (small) help engine feature hasn't
> been
> terribly popular.
>
> I'm working on enabling this in JSPWiki anyway, but won't bother
> submitting the patches here.
>
> By the way, I don't see cookies as a lot more secure. The cookie
> text is
> also sent in plain text in both the request and response bodies. There
> aren't many cases where someone can intercept the url but not the
> cookies. But thanks for the reference to OWASP; I'll have a look at
> what
> they say about that.
>
> Regards,
> Simon
>
> Andrew Jaquith schrieb:
>> Putting the session ID in the URL (which is I think what you are
>> asking about) is a fairly severe security risk. Cloning the session
>> becomes trivial if the URL is obtained.
>>
>> I know that in certain locales (Germany, for example), it is believed
>> that cookies represent an invasion of privacy. But, perversely,
>> banning cookies actually decreases the overall level security for
>> webapps because the session ID is now exposed in the URL. For this
>> reason, the practice of adding session IDs to webapp URLs has always
>> been discouraged by best-practice organizations such as OWASP.
>>
>> Janne's comment from 2006, I expect, still holds. We would encourage
>> anyone who wishes to eliminate cookies -- in spite of best-practice
>> advice from the security community -- to write their own patches. But
>> it is extremely unlikely that JSPWiki will ever incorporate a "no
>> cookie" (URL rewriting) feature.
>>
>> Andrew
>>
>> On Jun 18, 2008, at 10:20 AM, Simon Kitching wrote:
>>
>>> Hi,
>>>
>>> This email from 2006 says that "url rewriting" (ie having sessions
>>> without cookies) is not supported by JSPWiki. Is this still true for
>>> later releases?
>>> http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004
>>>
>>> Thanks,
>>> Simon
>>>
>>
>
Re: url rewriting supported?
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Yeah, but getting URLs simply, AND having some type-assurance over
> the parameters you pass, are diametrically opposed goals. :)
Why would they be?
> I have not looked at this in detail yet. A quick skim of it just
> now suggests that it is a little sparse so far. What sort of
> feedback/interaction are you looking for?
Currently it is really defined only for plugin writers and filter
writers. But it does lay some important groundwork (like WikiContext
and WikiPage being interfaces). Are the methods on them good or
not? What more is needed and what is not?
The point being - we need to define an "SDK" which is independent of
the latest craze. Something on which we can exert strong change
control and test binary compatibility against.
I would like to break our API into two pieces:
1. The stable SDK - that is, the org.apache.jspwiki.api package.
Won't change. You can rely on it. It is well-documented, though
sparse.
2. The "current" API. This is accessed in the old way of just
looking into the source code and trying to figure out WTF is going
on. Allows you to do extensive manipulation of stuff. We won't
guarantee it won't break, but it'll keep roughly the same all the time.
We have #2 currently, but no #1.
The chief motivation is that we have so many wonderful and nice
plugins written by people, and we haven't really cared about them at
all at this point. So while we're purposefully breaking everything,
I want to give them something they can rely on in the future.
The problem with building everything around a single UI library is
that it's brittle. If Stripes breaks compatibility, so shall we,
too. Not by choice, but by necessity. I want to get past that.
> That is a feature -- the .action suffix is what causes the
> StripesFilter to execute on the inbound side so that it can
> populate ActionBeans with correct parameters, run any events that
> are needed, check security, etc. However, the URLs are muddled
> generally only for things like form POST addresses. Users would see
> JSP URLs in their browser location bars. Directly addressing the
> JSP would still work.
Unfortunately, they don't. Whenever you post something, and Stripes
returns it back, you *will* see the Action URL. Which means that
users can grab the URL, and send it somewhere and hey, they've got a
wrong/broken URL. The users don't *care* whether it's only after a
POST, it'll just happen randomly.
IMO, it's a bug.
> By the way, the .action URLs also make it easy to create service
> URLs for things that don't have JSPs. AJAX or JSON calls, for
> example, could directly call the ActionBean they correspond to
> rather than being threaded through an AJAX servlet. This is, as you
> might imagine, incredibly useful. And with the integrated security
> annotations I've developed, we will be able to do this in a very
> secure way -- enforced and parameter-bound automatically through
> the StripesFilter, and -- here is the payoff -- *without writing a
> single line of code.*
For AJAX, yes, that's fine - because AJAX URLs can change since we
always send them over via the JS mechanism anyway. They're not
visible to the user anyway - might be to the developer, but not to
the user. But user-visible URLs?
StripesFilter works also for JSPs.
> So on balance -- I understand you don't like the .action suffixes.
> But they aren't what the user will see most of the time. And, they
> make life a lot easier for Dirk and other people who want to build
> more "web service" interfaces.
The problem is that users will see them *randomly*. And from what I
have learned, the user's don't understand random.
> Could we continue to use WikiContext, with all of its page-centric
> methods, as the superinterface for all actionbeans? Sure, but then
> we would have to continue referencing read ("faking") the page for
> those 'beans that have nothing to do with pages. This is why
> calling getPage() for the user prefs wiki context, today, returns
> "Main." That is confusing, and from the user's point of view an
> error condition. I'd rather we stop using WikiContext this way --
> that was what I meant by "overloading."
Fine, I just wouldn't like to call them ActionBeans on the API side,
since they imply Stripes. Besides, if WikiContext is an interface,
you can't use the ActionBeans anyway as the parent I/F. I'd rather
go with
AbstractWikiContext
+--WikiContext
+--GroupWikiContext
or something similar to that effect. The actual implementing classes
can then implement ActionBean.
/Janne
Re: url rewriting supported?
Posted by Andrew Jaquith <an...@mac.com>.
> I'm not too sure on the URLBuilder as well, since it makes it hard
> to just simply to "get an URL, dammit." Yes, it's flexible, but
> it's also, well, clunky.
Yeah, but getting URLs simply, AND having some type-assurance over the
parameters you pass, are diametrically opposed goals. :)
> Did you take a look at the new API proposal in SVN? I think we
> should build a good API library first, so that we can have more
> freedom in building our internal core.
I have not looked at this in detail yet. A quick skim of it just now
suggests that it is a little sparse so far. What sort of feedback/
interaction are you looking for?
> Hm. There's one problem with Stripes which I don't like and it's
> the fact that it muddles the URLs. If you enter with Wiki.jsp -
> then you e.g. run validation on a form, you end up on Wiki.action.
That is a feature -- the .action suffix is what causes the
StripesFilter to execute on the inbound side so that it can populate
ActionBeans with correct parameters, run any events that are needed,
check security, etc. However, the URLs are muddled generally only for
things like form POST addresses. Users would see JSP URLs in their
browser location bars. Directly addressing the JSP would still work.
By the way, the .action URLs also make it easy to create service URLs
for things that don't have JSPs. AJAX or JSON calls, for example,
could directly call the ActionBean they correspond to rather than
being threaded through an AJAX servlet. This is, as you might imagine,
incredibly useful. And with the integrated security annotations I've
developed, we will be able to do this in a very secure way -- enforced
and parameter-bound automatically through the StripesFilter, and --
here is the payoff -- *without writing a single line of code.*
So on balance -- I understand you don't like the .action suffixes. But
they aren't what the user will see most of the time. And, they make
life a lot easier for Dirk and other people who want to build more
"web service" interfaces.
> I wouldn't, since it's the officially promoted way to e.g. use the
> renderer engine in embedding systems. We can't break that one until
> 3.0.
Ok, never mind then. I am quite happy with 2.8 as it is. :)
>> The big problem is that WikiContext is a part of our official API,
>> so we can't remove any of that stuff.
I meant something a little different than what you interpreted.
WikiContext is pretty much here to stay -- I was not suggesting we
remove it. The issue is "overloading." Should it become the parent
interface for everything, or just for page-related stuff? If it's just
page-related, then that means for things that have nothing to do with
pages, we need a parent interface that does less (for example: a
generic interface for wiki actions that does not have getPage/setPage
methods).
That's the issue. Making WikiContext a pure page-specific sub-
interface is probably the best approach because it breaks a lot less
stuff. It just breaks the Group, UserPrefs/UserProfile and (probably)
Admin JSPs, because you can't pull a WikiContext from the request any
more -- you would need to cast to its parent interface
("WikiActionBean"). That was the "broken" stuff I mentioned. I think I
can do that without needing to do too many modifications to the .tags
package or the JSPs.
Could we continue to use WikiContext, with all of its page-centric
methods, as the superinterface for all actionbeans? Sure, but then we
would have to continue referencing read ("faking") the page for those
'beans that have nothing to do with pages. This is why calling
getPage() for the user prefs wiki context, today, returns "Main." That
is confusing, and from the user's point of view an error condition.
I'd rather we stop using WikiContext this way -- that was what I meant
by "overloading."
Again, the motivation here is not to remove WikiContext -- but to
figure out how to extract a meaningful parent interface from it, and
keeping the retrofits needed down to a minimum.
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> I'm not so concerned about regex parsing simply because I *think* it's
> possible to design a URL schema that doesn't require it, iff that
> schema
> is pretty exacting. I would myself prefer to avoid regex if
> possible, for
You can't avoid regexps in a rule-based model.
You can in a code-based model.
;-)
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> I don't follow. How? If we maintain a flat wiki namespace,
But we don't.
> are using
> wiki page names as we do now as oids, have one predicate and
> everything
> else is passed as query arguments we have a schema that looks like:
>
> http://www.acme.com/pages/PageName/get/?param1=name?param2=name
>
> What's wrong with that?
By your definition, that's not RESTful, then ;-)
And it will break.
>>
> I am writing a new app.
But we are discussing JSPWiki 3 architecture. And, the problem is
that the CleanURI feature isn't going to help you, because it is static.
> I'm not suggesting it is a strong requirement of yours, only that if
> I'm going to use JSPWiki and get it to fit into our larger service
> framework I'm going to need something like what Andrew has suggested
> can be provided via Stripes, and it'd be great if that URL schema was
> also the one used by the wiki generally. A very good fit, really.
I don't see any way that it could. Remember that the Stripes
URIBindings are static, enforced in *static code annotations*. So
you would need to fork your own version of JSPWiki.
> And if it were modular (I'm here telegraphing an email from you I
> just received) it might be possible to fit this onto a 2.8 implementa-
> tion by hooking it into the wiki in the same way as the existing URL
> constructors are handled. When we get to 3.0 we may have a nicer way
> of doing it but if well designed we wouldn't have to replace anything,
> just change the means of attachment/message passing.
No, I don't see that it would be possible without breaking the 2.8.
The Stripes stuff is a very, very invasive change, and at any rate,
we would be stuck with the URLConstructors anyway.
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>>> This presents more of a challenge. We need some way of transforming
>>> the inbound URL into a normal request -- with normal parameters -- so
>>> that Stripes can locate the right bean, [etc.]
>>> Originally I was thinking we'd need to write our own filter to do
>>> this, or use URLRewrite. It turns out some clever Stripes devs got
>>> there first. They call this the "clean URL" feature. It was initially
>>> a user contribution, but the Gregg and Tim liked it so much they put
>>> it into the trunk.
>>> I have been watching the 1.5 builds, but TOTALLY forgot about this.
>>> Needless to day, it completely solves the problem, and it makes my
>>> previous comments about needing an external filter totally obsolete.
>>> Assuming you buy into the Stripes Way, the URL scheme you describe
>>> can be completely accommodated.
>
> BTW, I think this is evil. It gives you a fixed URI scheme, and sooner
> or later you end up with URLs that look like /foo/-/-/-/a/-/-/-/c/-/-/-/
>
> You see them all around these days.
I don't follow. How? If we maintain a flat wiki namespace, are using
wiki page names as we do now as oids, have one predicate and everything
else is passed as query arguments we have a schema that looks like:
http://www.acme.com/pages/PageName/get/?param1=name?param2=name
What's wrong with that?
>>> "Clean URLs support both prefix mapping (/action/foo/{bar}) and
>>> extension mapping (/foo/{bar}.action). Any number of parameters
>>> and/or literals may be omitted from the end of a request URL."
>
> The problem is that you can't do it from the middle of the request.
>
>> Almost all of our present services are in need of an architectural
>> overview, and what we're trying to do is (sorry to the use the word
>> again, but) rationalize the URL schema.
>
> We can't without breaking the URLs of all the existing websites. *And*
> some of them are using the ShortViewURLConstructor and some of them are
> using the DefaultURLConstructor. I think this is a design parameter
> which we simply cannot afford to break.
That's not an issue since I wouldn't propose to use this with existing
websites. No existing website *can* change its URL schema constructor
without breaking all the bookmarks of all its current users. Even if
I *could* get the ShortURLConstructor to work with the CeryleWiki (and
I've not been able to since the directory level from the base URL won't
permit it, or some such thing), I have to deal with the fact that anyone
who has a bookmarked page or uses any URL reference to a page on my
site will get a 404 if I change my scheme. In my case I'll probably
just change it, but this is a non-issue for most *existing* sites -- I'm
only thinking of this for new sites.
> (And no, mod_rewrite is not an answer.)
>
>> What I'm thinking is that Janne doesn't sound all that enthusiastic
>> about this so it might have to fit into the application as another
>
> The Stripes stuff is great - IF you are writing a new app. If you're
> trying to retrofit it to the existing schema, I would very strongly
> hesitate to just use it because it's great and we have it - that'll end
> up in a translation layer in front of the Beans which just muddy the
> waters so that we can use Annotations. It'll be just like the Command
> superstructure, but in another form ;-)
I am writing a new app.
> Note that this CleanURI feature is new in Stripes 1.5 (which isn't even
> out yet in a stable form), and there have been tons of successful
> applications made in Stripes 1.4 and earlier. I don't see it as a
> strong requirement to enforce this architecture.
I'm not suggesting it is a strong requirement of yours, only that if
I'm going to use JSPWiki and get it to fit into our larger service
framework I'm going to need something like what Andrew has suggested
can be provided via Stripes, and it'd be great if that URL schema was
also the one used by the wiki generally. A very good fit, really.
And if it were modular (I'm here telegraphing an email from you I
just received) it might be possible to fit this onto a 2.8 implementa-
tion by hooking it into the wiki in the same way as the existing URL
constructors are handled. When we get to 3.0 we may have a nicer way
of doing it but if well designed we wouldn't have to replace anything,
just change the means of attachment/message passing.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
>> This presents more of a challenge. We need some way of
>> transforming the inbound URL into a normal request -- with normal
>> parameters -- so that Stripes can locate the right bean, [etc.]
>> Originally I was thinking we'd need to write our own filter to do
>> this, or use URLRewrite. It turns out some clever Stripes devs got
>> there first. They call this the "clean URL" feature. It was
>> initially a user contribution, but the Gregg and Tim liked it so
>> much they put it into the trunk.
>> I have been watching the 1.5 builds, but TOTALLY forgot about
>> this. Needless to day, it completely solves the problem, and it
>> makes my previous comments about needing an external filter
>> totally obsolete. Assuming you buy into the Stripes Way, the URL
>> scheme you describe can be completely accommodated.
BTW, I think this is evil. It gives you a fixed URI scheme, and
sooner or later you end up with URLs that look like /foo/-/-/-/
a/-/-/-/c/-/-/-/
You see them all around these days.
>>
>> "Clean URLs support both prefix mapping (/action/foo/{bar}) and
>> extension mapping (/foo/{bar}.action). Any number of parameters
>> and/or literals may be omitted from the end of a request URL."
The problem is that you can't do it from the middle of the request.
> Almost all of our present services are in need of an architectural
> overview, and what we're trying to do is (sorry to the use the word
> again, but) rationalize the URL schema.
We can't without breaking the URLs of all the existing websites.
*And* some of them are using the ShortViewURLConstructor and some of
them are using the DefaultURLConstructor. I think this is a design
parameter which we simply cannot afford to break.
(And no, mod_rewrite is not an answer.)
> What I'm thinking is that Janne doesn't sound all that enthusiastic
> about this so it might have to fit into the application as another
The Stripes stuff is great - IF you are writing a new app. If you're
trying to retrofit it to the existing schema, I would very strongly
hesitate to just use it because it's great and we have it - that'll
end up in a translation layer in front of the Beans which just muddy
the waters so that we can use Annotations. It'll be just like the
Command superstructure, but in another form ;-)
Note that this CleanURI feature is new in Stripes 1.5 (which isn't
even out yet in a stable form), and there have been tons of
successful applications made in Stripes 1.4 and earlier. I don't see
it as a strong requirement to enforce this architecture.
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> @URLBinding("@URLBinding("/pages/{page=Main}/{$event}")
> class PageActionBean {
> WikiPage getPage()
> void setPage(WikiPage)
> int getVersion()
> void setVersion(int)
> void view()
> void edit()
> void comment()
> }
Not dynamic, not good. Adding new actions requires modification of
existing code.
(No, the current one is not very good either for the same reason.
Each action should be a separate Bean so that template writers can
declare them at will from their own JARs.)
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Andrew Jaquith wrote:
> Murray --
>
> Ok, wanna turn the crank on this a little?
Yes, lets.
> My thought, after reading what you wrote, is that we (meaning: you and
> I) could probably hammer out something that bridges 1) what you want, a
> nicer RESTish URL format, and 2) what I've been thinking about with all
> of the automatic bean-binding goodies that will come with JSPWiki 3.0,
> courtesy of Stripes.
Andrew, first of all: thanks very much for taking the time and effort
to explain all of this. It took two readings but I understand it, and
it's brilliant. Yes, it ties us into Stripes, but basically the code
could be replaced in five years by whatever is the latest trend in
five years (none of that matters, really) because the real API is the
URL and the constitution of the messages passed between the URL handler
and the application, and those messages should be highly rational and
form their own mini-API without any extra work (heck, it's already
there!).
> 1) STRIPES IN 60 SECONDS
>[...]
> So far, that's pretty great, huh? We've gone through the entire bean
> resolution, binding and event execution lifecycle without writing any
> special code -- it's all done via simple annotations. Best of all, we
> get to rip out lots of crappy JSP scriptlet code.
Yes, great stuff.
> 2) WHAT ABOUT MURRAY'S CLEAN URLS?
>
> Assuming you follow the logic here, you can see how the
> resolution/binding/event lifecycle works in a straight-ahead,
> traditional URL format (e.g., path?param=value=¶m=value).
>
> Now, let's apply this to a "clean URL" scenario like the one you described:
>
> http://murray.org/{subject}/{predicate}/ [optional "adjectives"]
>
> Using our example, it might look like this:
>
> /pages/Foo/?event=create
>
> or maybe: /pages/Foo/create
>
> This presents more of a challenge. We need some way of transforming the
> inbound URL into a normal request -- with normal parameters -- so that
> Stripes can locate the right bean, [etc.]
>
> Originally I was thinking we'd need to write our own filter to do this,
> or use URLRewrite. It turns out some clever Stripes devs got there
> first. They call this the "clean URL" feature. It was initially a user
> contribution, but the Gregg and Tim liked it so much they put it into
> the trunk.
>
> I have been watching the 1.5 builds, but TOTALLY forgot about this.
> Needless to day, it completely solves the problem, and it makes my
> previous comments about needing an external filter totally obsolete.
> Assuming you buy into the Stripes Way, the URL scheme you describe can
> be completely accommodated.
Very exciting, especially since the investment in code is so minimal,
the functionality so rationalized, and the result just works.
> Anyway, the new Clean URL feature works like this (from the Stripes 1.5
> Javadoc):
>
> "Stripes supports "Clean URLs" through the UrlBinding annotation.
> [...]
> "Clean URL parameters can be assigned default values using the =
> operator. For example,@UrlBinding("/foo/{bar=abc}/{baz=123}"). If a
> parameter with a default value is missing from a request URL, it will
> still be made available as a request parameter with the default value.
> Default values are automatically embedded when building URLs with the
> Stripes JSP tags. The default value for $event is determined from the
> DefaultHandler and may not be set in the @UrlBinding.
>
> "Clean URLs support both prefix mapping (/action/foo/{bar}) and
> extension mapping (/foo/{bar}.action). Any number of parameters and/or
> literals may be omitted from the end of a request URL."
This is great. I spent some hours last week writing a URL remapper and
this does it via an annotation; brilliant.
> You can see some addition comments on the development of the feature here:
>
> http://www.stripesframework.org/jira/browse/STS-262
>
> So-- to wrap up our previous example, the @URLBinding annotation for our
> PageActionBean class would look like this:
>
> @URLBinding("/pages/{page=Main}/?event={$event}")
>
> or:
>
> @URLBinding("/pages/{page=Main}/{$event}")
>
> Nice, huh? No coding needed.
Yes, a very clean design. Thanks.
[...]
> 4) THINKING ABOUT BEANS AND EVENTS
>
> The difficult part of all this is figuring out how to map ActionBeans to
> what we understand today as WikiContexts, and to the URL scheme you have
> suggested. It all comes down to how you look at things:
>
> - Do you select a page, then take an action on it? (view, edit, comment)
> - Or do you "edit" something... and specify that that something is a
> particular page?
>
> The URL scheme you suggested implies the first approach. Today's JSP
> scheme implies the second.
Yes, but as I just replied to Janne, my own requirements are for a
REST-ful design that doesn't embed any implementation detail in the
URL (e.g., ".action") and fully separates noun from verb.
Almost all of our present services are in need of an architectural
overview, and what we're trying to do is (sorry to the use the word
again, but) rationalize the URL schema. We're for one large project
working with a major vendor who uses a term called an "intellectual
entity" or IE, similar to what in RDF are called "resources". These
form the nouns of our services, such that there is a canonical URL
to identify the IE. This can be considered both independently of a
base URL or with it, e.g.,
oid: isbn0-87685-479-X
resolveable oid: http://www.acme.com/item/isbn0-87685-479-X
So we have a strong requirement that from the beginning of the
base URL to the end of the oid forms a canonical reference to
an oid.
This works well with a scheme where the last or semi-last token
in a URL is the oid, the last case using the last as the verb. I'm
not wedded to either approach of where the verb should sit.
> Personally, I like the "object" followed by "verb" idea (the first
> approach). It maps fairly cleanly to the Stripes ActionBean properties +
> event model.
When I read the above I smiled, as that's exactly what I'm aiming
at. So we can have either
http://www.acme.com/item/isbn0-87685-479-X/get/
or
http://www.acme.com/item/isbn0-87685-479-X/?action=get
as far as I'm concerned. I'm guessing that my teammates might go with
the latter (given some designs I've seen) but as I mentioned I do
have *some* flexibility (I think).
> Thus, a hypothetical PageActionBean class ("the action bean
> you use to 'do stuff' with pages") might include the following
> properties and methods:
>
> @URLBinding("@URLBinding("/pages/{page=Main}/{$event}")
> class PageActionBean {
> WikiPage getPage()
> void setPage(WikiPage)
> int getVersion()
> void setVersion(int)
> void view()
> void edit()
> void comment()
> }
>
> The view, edit and comment methods are the events. These are also, at
> least in theory, "request contexts" as well. (It is easy to see how
> these would map to WikiContext.VIEW, .EDIT, and .COMMENT...)
>
> Murray, assuming I have not bored the crap out of you, what do you
> think? Want to brainstorm some more about "nouns" (action beans) and
> "verbs" (events)? Got the full schema to share?
Bored? Hardly. No, this is great, I'm keen to try this out.
What I'm thinking is that Janne doesn't sound all that enthusiastic
about this so it might have to fit into the application as another
URLConstructor, or as a sort of proxy that hands off services to
the WikiEngine, dunno. If it were handled as a modular, standalone
web service with an open backend API we'd just need the glue to
hook it into the WikiEngine et al, and it could be reused for other
related web services (those layers I mentioned) that provide alterna-
tive access to the wiki repository, e.g. a web service alternative
to some of the XML-RPC functionality, interwiki or wiki-hive features,
the means of hooking the repository into analysis or preservation
system, etc.
In other words, the Stripes stuff you've mentioned sounds like it
could be useful for all sort of things. I'm just not sure how it
might fit into JSPWiki itself at this point.
As for the URL schema, you've got most of it at this point, unless
you mean the specifics of the verb names, etc. I don't mean to
sound secretive at all, but I just don't think the specifics matter
all that much at this point, i.e., they'd like just be implementation
details as far as I'm concerned, some constant values we can argue
over at some other time (I wouldn't want to get bogged down in that
kind of thing).
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Digging a little deeper... when the StripesFilter encounters a URL
> with a .action suffix, OR a JSP contains a stripes:useActionBean
> tag, the StripesFilter goes through a defined lifecycle that:
You *could* of course map all *.jsp URLs to the given ActionBean as
well, doing away with JSPs altogether. Though that would mean that
it would be rather complicated to add any new JSPs.
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Andrew Jaquith <an...@mac.com>.
Murray --
Ok, wanna turn the crank on this a little?
My thought, after reading what you wrote, is that we (meaning: you and
I) could probably hammer out something that bridges 1) what you want,
a nicer RESTish URL format, and 2) what I've been thinking about with
all of the automatic bean-binding goodies that will come with JSPWiki
3.0, courtesy of Stripes.
1) STRIPES IN 60 SECONDS
First, Stripes in 60 seconds. The core unit of data in Stripes is the
ActionBean. ActionBeans have properties (getters/setters) and events
(methods specially annotated). ActionBeans are essentially fairly
lightweight objects that model the range of activities you want to
accomplish (using a form POST or AJAX, for example) -- these are the
"verbs." The properties map cleanly to request parameters -- these are
the nouns and adjectives. What Stripes does is inspect the request
URL, and automatically wire up the right ActionBean, making sure that
the "nouns and adjectives" are mapped to parameters, and that the
right activity is executed.
Digging a little deeper... when the StripesFilter encounters a URL
with a .action suffix, OR a JSP contains a stripes:useActionBean tag,
the StripesFilter goes through a defined lifecycle that:
1) locates the and instantiates the correct ActionBean based on
the .action URL or the bean class specified in the useActionBean tag
2) binds parameters passed in the request to properties (getters/
setters) in the ActionBean
3) calls the "event method" specified in the URL (validating the
properties based on annotated instructions). If no event was
specified, it executes the default event (generally forwarding to the
"display JSP," like Wiki.jsp)
For example, suppose we post a URL:
Wiki.action?page=Foo?&_eventName=create
Stripes will inspect the ActionBeans it knows about. Suppose it finds
one called PageActionBean that has a matching @URLBinding of
Wiki.action. It knows, aha, I need to create a PageActionBean and
stash it into the request as an attribute.
Next, it sees that there you supplied a parameter called "page", and
it notes also that PageActionBean has a setPage(WikiPage) method. It
will say, aha, we need to call setPage() with the value "Foo". Or more
correctly, it will use its TypeConverter system to look up the
WikiPage object corresponding to string "Foo" and set it. (I've
written a TypeConverter for WikiPage already; very simple.)
Next, it sees the special parameter _eventName and its value "create",
which is the event it needs to call. It will invoke the create()
method, making sure to run any validation routines we've asked it to
run (specified by the @Validate annotation on the bean properties).
(Sidebar: I have written another annotation that expresses the
Permissions the user must have to run the event.)
Lastly, the create() method will forward to Edit.jsp to display the
wiki editor.
So far, that's pretty great, huh? We've gone through the entire bean
resolution, binding and event execution lifecycle without writing any
special code -- it's all done via simple annotations. Best of all, we
get to rip out lots of crappy JSP scriptlet code.
2) WHAT ABOUT MURRAY'S CLEAN URLS?
Assuming you follow the logic here, you can see how the resolution/
binding/event lifecycle works in a straight-ahead, traditional URL
format (e.g., path?param=value=¶m=value).
Now, let's apply this to a "clean URL" scenario like the one you
described:
http://murray.org/{subject}/{predicate}/ [optional "adjectives"]
Using our example, it might look like this:
/pages/Foo/?event=create
or maybe: /pages/Foo/create
This presents more of a challenge. We need some way of transforming
the inbound URL into a normal request -- with normal parameters -- so
that Stripes can locate the right bean, bind its properties correctly,
etc. Specifically: it needs to somehow "know" that /pages meant "find
the PageActionBean", and that /Foo meant "call setPage() with page
Foo" and that /create meant, "call the 'create' event once you've done
all that."
Originally I was thinking we'd need to write our own filter to do
this, or use URLRewrite. It turns out some clever Stripes devs got
there first. They call this the "clean URL" feature. It was initially
a user contribution, but the Gregg and Tim liked it so much they put
it into the trunk.
I have been watching the 1.5 builds, but TOTALLY forgot about this.
Needless to day, it completely solves the problem, and it makes my
previous comments about needing an external filter totally obsolete.
Assuming you buy into the Stripes Way, the URL scheme you describe can
be completely accommodated.
Anyway, the new Clean URL feature works like this (from the Stripes
1.5 Javadoc):
"Stripes supports "Clean URLs" through the UrlBinding annotation.
Parameters may be embedded in the URL by placing the parameter name
inside braces ({}). For example, @UrlBinding("/foo/{bar}/{baz}") maps
the action to "/foo" and indicates that the "bar" and "baz" parameters
may be embedded in the URL. In this case, the URL /foo/abc/123 would
invoke the action with bar set to "abc" and baz set to "123". The
literal strings between parameters can be any string.
"The special parameter name $event may be used to embed the event name
in a clean URL. For example, given@UrlBinding("/foo/{$event}") the
"bar" event could be invoked with the URL /foo/bar.
"Clean URL parameters can be assigned default values using the =
operator. For example,@UrlBinding("/foo/{bar=abc}/{baz=123}"). If a
parameter with a default value is missing from a request URL, it will
still be made available as a request parameter with the default value.
Default values are automatically embedded when building URLs with the
Stripes JSP tags. The default value for $event is determined from the
DefaultHandler and may not be set in the @UrlBinding.
"Clean URLs support both prefix mapping (/action/foo/{bar}) and
extension mapping (/foo/{bar}.action). Any number of parameters and/or
literals may be omitted from the end of a request URL."
You can see some addition comments on the development of the feature
here:
http://www.stripesframework.org/jira/browse/STS-262
So-- to wrap up our previous example, the @URLBinding annotation for
our PageActionBean class would look like this:
@URLBinding("/pages/{page=Main}/?event={$event}")
or:
@URLBinding("/pages/{page=Main}/{$event}")
Nice, huh? No coding needed.
3) OUTBOUND URLS
So far I've described how inbound URLs would be parsed and mapped.
What about the outbound case (URL generation)?
We would need to write a custom URL constructor that might, for
example, query the ActionBeans for the correct format, then format the
URL according to that format. The Stripes URLBuilder class isn't
suitable for that, because it just knows how to build URLs of the
traditional sort. (Although the Stripes guys say they intend to make
it match the @URLBinding format soon...)
4) THINKING ABOUT BEANS AND EVENTS
The difficult part of all this is figuring out how to map ActionBeans
to what we understand today as WikiContexts, and to the URL scheme you
have suggested. It all comes down to how you look at things:
- Do you select a page, then take an action on it? (view, edit, comment)
- Or do you "edit" something... and specify that that something is a
particular page?
The URL scheme you suggested implies the first approach. Today's JSP
scheme implies the second.
Personally, I like the "object" followed by "verb" idea (the first
approach). It maps fairly cleanly to the Stripes ActionBean properties
+ event model. Thus, a hypothetical PageActionBean class ("the action
bean you use to 'do stuff' with pages") might include the following
properties and methods:
@URLBinding("@URLBinding("/pages/{page=Main}/{$event}")
class PageActionBean {
WikiPage getPage()
void setPage(WikiPage)
int getVersion()
void setVersion(int)
void view()
void edit()
void comment()
}
The view, edit and comment methods are the events. These are also, at
least in theory, "request contexts" as well. (It is easy to see how
these would map to WikiContext.VIEW, .EDIT, and .COMMENT...)
Murray, assuming I have not bored the crap out of you, what do you
think? Want to brainstorm some more about "nouns" (action beans) and
"verbs" (events)? Got the full schema to share?
Andrew
On Jul 7, 2008, at 6:06 PM, Murray Altheim wrote:
> Murray Altheim wrote:
> [...]
>> In the above scheme we can obtain the base URL, the collection
>> hierarchy
>> and object identifier all without regex, just parsing the '/'
>> delimiters
>> via indexOf(). If we use the '?' as the delimiter between the
>> absolute
>> identifier of the intellectual entity (IE, to use the term we're
>> using
>> here locally), then everything after that is parseable either by
>> going
>> one '/' forward or backward, and everything else is a parameter
>> available
>> via the HTTPServletRequest.
>
> I didn't finish a thought (how unusual!).
>
> The idea was that there's a subject, predicate and object embedded in
> that URL, with the '?' acting as a delimiter or boundary of sorts:
>
> http://www.acme.org/wiki/ pages/ PageName/ get/ ['?' optional
> params]
> or
> http://www.acme.org/wiki/ pages/ PageName/ '?' action=get
>
> abstracted as:
>
> subject/ predicate/ [optional "adjectives"]
> or
> subject/ '?' predicate [optional "adjectives"]
>
> which means parsing comes down to traveling one '/' from either the
> end
> of the URL or from '?', if the latter exists. In either case I don't
> think we need regex.
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray07 at altheim.com>
> === = =
> http://www.altheim.com/murray/ =
> = ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
> = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Murray Altheim wrote:
[...]
> In the above scheme we can obtain the base URL, the collection hierarchy
> and object identifier all without regex, just parsing the '/' delimiters
> via indexOf(). If we use the '?' as the delimiter between the absolute
> identifier of the intellectual entity (IE, to use the term we're using
> here locally), then everything after that is parseable either by going
> one '/' forward or backward, and everything else is a parameter available
> via the HTTPServletRequest.
I didn't finish a thought (how unusual!).
The idea was that there's a subject, predicate and object embedded in
that URL, with the '?' acting as a delimiter or boundary of sorts:
http://www.acme.org/wiki/ pages/ PageName/ get/ ['?' optional params]
or
http://www.acme.org/wiki/ pages/ PageName/ '?' action=get
abstracted as:
subject/ predicate/ [optional "adjectives"]
or
subject/ '?' predicate [optional "adjectives"]
which means parsing comes down to traveling one '/' from either the end
of the URL or from '?', if the latter exists. In either case I don't
think we need regex.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Andrew Jaquith wrote:
[...]
> For 3.0, my preference has been to use a plain addressing scheme like
> the current DefaultURLConstructor. It doesn't require any special
> decoding/remapping on the inbound side, and outbound URL construction is
> easy. However, an URL scheme like the one you suggested is good too. In
> theory, we could use URLRewrite. Janne has also raised concerns about
> performance because of its reliance on regular expressions. I am less
> concerned about that, and more concerned about the fact that you need to
> be able to reference the HTTP response object (and its encodeURL()
> method) to make it work.
I'm not so concerned about regex parsing simply because I *think* it's
possible to design a URL schema that doesn't require it, iff that schema
is pretty exacting. I would myself prefer to avoid regex if possible, for
the reasons Janne has suggested, partly because the service I'm looking
at could become a real bottleneck since it's effectively being proposed
for use as a kind of proxy for a high-traffic web service (e.g., it
could in theory be a pass-through for all of a site's traffic).
> The other approach would be a new ("better") URL constructor scheme.
> Either way, we will continue to need 1) a filter (to remap the incoming
> URLs to a proper request format and forward the correct destination JSP)
> and 2) some kind of URL construction algorithm.
> On Jul 7, 2008, at 4:24 PM, Murray Altheim wrote:
>>
>> baseURL collectionHierarchy [objectId] action ['?' parameters]
>>
>> e.g.,
>>
>> http://www.acme.org/wiki/ pages/ PageName/ get/
In the above scheme we can obtain the base URL, the collection hierarchy
and object identifier all without regex, just parsing the '/' delimiters
via indexOf(). If we use the '?' as the delimiter between the absolute
identifier of the intellectual entity (IE, to use the term we're using
here locally), then everything after that is parseable either by going
one '/' forward or backward, and everything else is a parameter available
via the HTTPServletRequest.
For example, we either assume the second-to-last '/'-delimited token is
the oid ("PageName"), with the last token the action:
http://www.acme.org/wiki/pages/PageName/put/
or we obtain the action as a parameter and assume the last token is
the oid:
http://www.acme.org/wiki/pages/PageName/?action=get
The former is *slightly* problematic if there is no oid, e.g.,
http://www.acme.org/wiki/pages/search/?q=term
but that's possibly handled by counting tokens or simply not using an
oid at all
http://www.acme.org/wiki/pages/?action=search?q=term
or
http://www.acme.org/wiki/pages/?q=term (search is implied by
the presence of 'q')
The devil may be in the details but this *seems* like a workable plan.
If we want to permit a collection hierarchy rather than simply a flat
namespace this might get more complicated, but only if we permit an
arbitrary depth (something I don't need).
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Andrew Jaquith <an...@mac.com>.
Murray --
The kind of URL scheme you describe is very interesting, and it is
indeed related to this whole discussion on URL construction.
URLConstructor isn't the best name, really, because it actually
understates its role. It also performs URL *parsing*.
My earlier message about URLRewrite relates to this. On the inbound
side, "something" needs to transform the long URL (http://www.acme.org/wiki/pages/PageName/edit/
) into a proper resource path, with parsed and decoded parameters.
URLRewrite does this, as a filter. So does our own WikiServlet filter,
albeit not using the syntax you gave.
For 3.0, my preference has been to use a plain addressing scheme like
the current DefaultURLConstructor. It doesn't require any special
decoding/remapping on the inbound side, and outbound URL construction
is easy. However, an URL scheme like the one you suggested is good
too. In theory, we could use URLRewrite. Janne has also raised
concerns about performance because of its reliance on regular
expressions. I am less concerned about that, and more concerned about
the fact that you need to be able to reference the HTTP response
object (and its encodeURL() method) to make it work.
The other approach would be a new ("better") URL constructor scheme.
Either way, we will continue to need 1) a filter (to remap the
incoming URLs to a proper request format and forward the correct
destination JSP) and 2) some kind of URL construction algorithm.
Andrew
On Jul 7, 2008, at 4:24 PM, Murray Altheim wrote:
> One of the things I've been working on (both related and unrelated to
> JSPWiki) is a web service URL schema providing read and write access
> to the wiki, in particular the wiki's page provider. Without going
> into detail about that I thought I might at least mention the idea
> of REST-fully regularizing *all* of the URLs used by JSPWiki to a
> common approach, i.e. (optional components in square brackets):
>
> baseURL collectionHierarchy [objectId] action ['?' parameters]
>
> e.g.,
>
> http://www.acme.org/wiki/ pages/ PageName/ get/
>
> This would in the future permit a collection hierarchy where 'pages/'
> currently exists, with 'PageName' as object ID (oid) potentially
> replaced by any kind of identifier (pages may be identified by name
> or by some other kind of identifier that survives across renames --
> title).
>
> http://www.acme.org/wiki/pages/PageName/get/
> http://www.acme.org/wiki/pages/PageName/edit/
> http://www.acme.org/wiki/pages/PageName/put/
> http://www.acme.org/wiki/pages/search/?q=term
>
> (the actual action names aren't important) or alternately, including
> the action name as a parameter:
>
> http://www.acme.org/wiki/pages/PageName/?action=get
> http://www.acme.org/wiki/pages/PageName/?action=edit
> http://www.acme.org/wiki/pages/PageName/?action=put
> http://www.acme.org/wiki/pages/?action=search&q=term
>
> allowing things like:
>
> http://www.acme.org/wiki/pages/PageName/?action=get&format=html
> http://www.acme.org/wiki/pages/PageName/?action=get&format=xml
> http://www.acme.org/wiki/pages/PageName/?action=get&format=text
>
> etc., with advantages and disadvantages to each.
>
> Has there been any thought amongst other members of the team in
> writing
> a more REST-ful URL constructor? Perhaps as the default? While I do
> understand dealing with legacy issues it'd be nice to just have a
> simple,
> REST-ful URL that just worked. It's been one of those things I've
> never
> been able to get working consistently in JSPWiki across all
> installations.
>
> I don't have it working yet but I basically have been writing a web
> service that would provide complete access to the wiki's functionality
> using a schema similar to the above. The question for me is how
> difficult it'd be in rewriting the JSPs to generate URLs as according
> to the web service instead of the existing setting, which of course
> led me to think that the whole web service is really just an
> alternative
> URL constructor...
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray07 at altheim.com>
> === = =
> http://www.altheim.com/murray/ =
> = ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
> = = =
>
> Boundless wind and moon - the eye within eyes,
> Inexhaustible heaven and earth - the light beyond light,
> The willow dark, the flower bright - ten thousand houses,
> Knock at any door - there's one who will respond.
> -- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <ja...@iki.fi>.
I think using Stripes as you've previously outlined without using
CleanURIs is a good idea. I figured that that is the baseline, and
that you are now proposing a delta which in my opinion is a mistake.
I've essentially been rehashing the same argument all over again -
Stripes CleanURIs do not fit the bill. I just grew tired of typing
the same stuff again, so I became categorical. All the arguments are
available in the previous emails.
/Janne
On Wed, Jul 09, 2008 at 09:43:21AM -0400, Andrew Jaquith wrote:
> Janne --
>
> I was expecting constructive -- rather than categorical -- comments
> from you. I did not perceive that you had many positive suggestions,
> and that disappoints me.
>
> I will respond in detail later, but not today.
>
> Andrew
>
> On Jul 9, 2008, at 3:01 AM, Janne Jalkanen wrote:
>
> >>I actually prefer using the '/' since it sideways fits into my
> >>existing
> >>URL schema. My schema:
> >>
> >> baseURL collectionHierarchy [objectId] action ['?' parameters]
> >>
> >>Janne's scheme (from what I understand):
> >>
> >> baseURL [collectionHierarchy/objectId] action ['?' parameters]
> >
> >Close, but no. The DefaultURLConstructor schema is
> >
> >baseURL action [collectionHierarchy/objectId] ['?' parameters].
> >
> >What I am just arguing that the schema that you want *requires*
> >code. Or mod_rewrite. Can't be done with Stripes automatically.
> >
> >>be resolvable, which in this system means an absolute URL. If
> >>Stripes is
> >>capable of parsing an arbitrary depth collection hierarchy (or
> >>directory
> >>structure, if that's what we're essentially mirroring), then that's
> >>fine.
> >
> >No, it cannot.
> >
> >>I really hope we don't have to use some ugly syntax for that. I don't
> >>have a requirement for arbitrary depth at all, nor can I foresee
> >>that.
> >>It's just too ugly and complicated for most users. Wikis have been
> >>flat
> >>since their inception and I'm fine with them being flat.
> >
> >The point is that you don't have to use them. However, for some
> >cases, the flat namespace is a problem (like the Weblog plugin -
> >currently we have to rely on naming conventions to identify pages,
> >and you know how much of a mess that becomes. Would be much nicer
> >to just embed them as subpages for the current page.)
> >
> >>It's really hard to imagine that annotations could be less flexible
> >>than
> >>code.
> >
> >They are, since everything in them needs to be a static value. It
> >cannot be recomputed at runtime.
> >
> >>I don't see that as a barrier to adoption. And if we know we're
> >>going to
> >>using Stripes in 3.0 I can't see any reason not to *begin* to use
> >>it now.
> >
> >There is, since it requires a massive change to the internals of
> >JSPWiki (or else it won't be useful).
> >
> >/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Andrew Jaquith <an...@mac.com>.
Janne --
I was expecting constructive -- rather than categorical -- comments
from you. I did not perceive that you had many positive suggestions,
and that disappoints me.
I will respond in detail later, but not today.
Andrew
On Jul 9, 2008, at 3:01 AM, Janne Jalkanen wrote:
>> I actually prefer using the '/' since it sideways fits into my
>> existing
>> URL schema. My schema:
>>
>> baseURL collectionHierarchy [objectId] action ['?' parameters]
>>
>> Janne's scheme (from what I understand):
>>
>> baseURL [collectionHierarchy/objectId] action ['?' parameters]
>
> Close, but no. The DefaultURLConstructor schema is
>
> baseURL action [collectionHierarchy/objectId] ['?' parameters].
>
> What I am just arguing that the schema that you want *requires*
> code. Or mod_rewrite. Can't be done with Stripes automatically.
>
>> be resolvable, which in this system means an absolute URL. If
>> Stripes is
>> capable of parsing an arbitrary depth collection hierarchy (or
>> directory
>> structure, if that's what we're essentially mirroring), then that's
>> fine.
>
> No, it cannot.
>
>> I really hope we don't have to use some ugly syntax for that. I don't
>> have a requirement for arbitrary depth at all, nor can I foresee
>> that.
>> It's just too ugly and complicated for most users. Wikis have been
>> flat
>> since their inception and I'm fine with them being flat.
>
> The point is that you don't have to use them. However, for some
> cases, the flat namespace is a problem (like the Weblog plugin -
> currently we have to rely on naming conventions to identify pages,
> and you know how much of a mess that becomes. Would be much nicer
> to just embed them as subpages for the current page.)
>
>> It's really hard to imagine that annotations could be less flexible
>> than
>> code.
>
> They are, since everything in them needs to be a static value. It
> cannot be recomputed at runtime.
>
>> I don't see that as a barrier to adoption. And if we know we're
>> going to
>> using Stripes in 3.0 I can't see any reason not to *begin* to use
>> it now.
>
> There is, since it requires a massive change to the internals of
> JSPWiki (or else it won't be useful).
>
> /Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> I actually prefer using the '/' since it sideways fits into my
> existing
> URL schema. My schema:
>
> baseURL collectionHierarchy [objectId] action ['?' parameters]
>
> Janne's scheme (from what I understand):
>
> baseURL [collectionHierarchy/objectId] action ['?' parameters]
Close, but no. The DefaultURLConstructor schema is
baseURL action [collectionHierarchy/objectId] ['?' parameters].
What I am just arguing that the schema that you want *requires*
code. Or mod_rewrite. Can't be done with Stripes automatically.
> be resolvable, which in this system means an absolute URL. If
> Stripes is
> capable of parsing an arbitrary depth collection hierarchy (or
> directory
> structure, if that's what we're essentially mirroring), then that's
> fine.
No, it cannot.
> I really hope we don't have to use some ugly syntax for that. I don't
> have a requirement for arbitrary depth at all, nor can I foresee that.
> It's just too ugly and complicated for most users. Wikis have been
> flat
> since their inception and I'm fine with them being flat.
The point is that you don't have to use them. However, for some
cases, the flat namespace is a problem (like the Weblog plugin -
currently we have to rely on naming conventions to identify pages,
and you know how much of a mess that becomes. Would be much nicer to
just embed them as subpages for the current page.)
> It's really hard to imagine that annotations could be less flexible
> than
> code.
They are, since everything in them needs to be a static value. It
cannot be recomputed at runtime.
> I don't see that as a barrier to adoption. And if we know we're
> going to
> using Stripes in 3.0 I can't see any reason not to *begin* to use
> it now.
There is, since it requires a massive change to the internals of
JSPWiki (or else it won't be useful).
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Andrew Jaquith wrote:
> Interesting thread! You guys had me at a disadvantage -- I was on a
> plane from Latin America this morning, and have not been able to respond
> until now.
>
> I think I smell a resolution in the air. It is, indeed, to use Stripes
> as the "backing technology" for short URLs. Doing this gets us
> compatibility with all three current URLConstructors. Here's why:
>
> First, let me state what I think I heard from Janne.
>
> #1: we have to stay compatible with ShortURLConstructor
> #2: we have to stay compatible with DefaultURLConstructor too
> #3: Janne has no interest in coming up with a new scheme, but is happy
> to let "others" (read: Murray) go crazy if they want to, outside of the
> core distro
> #4: despite restrictions 1, 2, and 3, the URL scheme needs to somehow
> accommodate subpages and wiki spaces
> #5: we assume that the delimiter for spaces and sub-pages is the same as
> the one separating subpath in the URL (/)
>
> Assumption #5 is dubious IMHO, but let's assume all of the others are
> hard requirements.
I actually prefer using the '/' since it sideways fits into my existing
URL schema. My schema:
baseURL collectionHierarchy [objectId] action ['?' parameters]
Janne's scheme (from what I understand):
baseURL [collectionHierarchy/objectId] action ['?' parameters]
The resulting URL is the same in both cases but the schema different. If
we consider that the absolute oid is the combination of baseURL and
relative oid then it makes no difference. OTOH, if we consider that the
collection hierarchy can have an arbitrary depth but use a *different*
delimiter than '/' things might get problematic. But since Janne seems to
want '/' I think we're fine. In the end the Intellectual Entity needs to
be resolvable, which in this system means an absolute URL. If Stripes is
capable of parsing an arbitrary depth collection hierarchy (or directory
structure, if that's what we're essentially mirroring), then that's fine.
> Even with these constraints, we can still use
> @URLBindings for inbound parsing. Here's why:
[...]
> So -- if we have 1) the DefaultURLConstructor covered via
> stripes:useActionBean and 2) the ShortURLConstructor covered via
> URLBindings, then by definition we also have 3) ShortViewURLConstructor
> covered. Requirement #3 (other URL schemes) is not met, but there is
> always mid_rewrite for those cases.
>
> The wildcard here is what happens with wikispaces and nested pages. Best
> case: Stripes does not care what is used as a delimiter, even a '/'.
> Worst case: Stripes does care, so we use a different delimiter, like a
> colon.
I really hope we don't have to use some ugly syntax for that. I don't
have a requirement for arbitrary depth at all, nor can I foresee that.
It's just too ugly and complicated for most users. Wikis have been flat
since their inception and I'm fine with them being flat. I can say I
have *no* requirement for hierarchy, and if there was one I'd hope it
only go one level (i.e., I'd really hate to see subpages of subpages
of subpages on a wiki, it would add complexity, kill interoperability
and confuse the hell out of most people). Most of the requirements for
subpages can be handled in other ways, such as facets, tags, categories,
etc.
But I don't want to enter to deep into discussion about this as it's
a black hole.
> Now, this kind of throws out Murray's particular scenario, but it does
> neatly give us, essentially, solid backwards compatibility and much
> better request binding, and great forward compatibility. We would still
> need an improved URL constructor class for the short URL case, which
> would rely on the URLBindings for instructions on how to make the URLs.
I don't see how this doesn't work with my scenario; indeed it still seems
to fit. Since I *think* we see eye-to-eye on this please clarify.
> We would effectively be trading code for annotations. Personally, I
> think that is a good thing, because it makes it easier to create new
> ActionBeans (features!)
It's really hard to imagine that annotations could be less flexible than
code. If we begin to rely on Stripes and then in the future decide to
dump it, as I mentioned before, the essential API contract is the URL
schema and the messaging passed back and forth between the URL handler
and the application. If in dumping Stripes we had to manually construct
what Stripes is doing with annotations that would simply be an exercise;
I don't see that as a barrier to adoption. And if we know we're going to
using Stripes in 3.0 I can't see any reason not to *begin* to use it now.
What Andrew has proposed seems almost completely plugin-and-play with
what is current in the code base. If not, then I'm not understanding
him correctly.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Andrew Jaquith <an...@mac.com>.
Janne --
I have done some in-depth testing of clean URLs in Stripes 1.5-RC1.
Based on my testing, I have concluded that there are several new facts
you should be aware of.
1) Stripes clean URLs supports slashes inside of extracted parameters.
That means sub-pages ("Foo/Bar/TestPage"), can be passed and they will
be extracted. The existing (in my 3.0 branch) WikiPageTypeConverter
would only need a small enhancement to properly locate pages with
hierarchical paths.
2) When using the Stripes URLBuilder with an ActionBean, it constructs
clean URLs, well, cleanly. Parameters not otherwise specified in the
pattern are sensibly appended to the generated URL, as you would
expect. This is good.
3) The Stripes UrlBindingFactory class that matches incoming URLs with
UrlBindings does not use regular expressions, and looks fairly well-
written and efficient. It does NOT, at this time, parse parameters
appended to the clean URL. I have uploaded a patch to the Stripes JIRA
site that adds this enhancement.
4) The UrlBindingFactory has many helper methods for parsing URLs that
do NOT depend on @URLBinding class annotations. In particular, this
means that URL binding definitions could be provided from an external
source -- for example, a config file.
The cumulative effect of these facts means that the Stripes approach
is viable. In short, I think you should re-consider your previous
objections. :)
Now, as to your comments:
> I think it is a hard requirement, for the following reasons:
As I mentioned, my testing shows that clean URL parameter values that
contain slashes are parsed correctly. You previously stated that
"Stripes cannot guess when a slash is a part of a page name, and when
it is an action." I assure you that it can, and with the ShortURL
scheme in particular.
> Wrong. It still won't cover the subpages or attachments. Also, it
> won't cover Murray's requirement.
It does. Also Murray and I have been talking about his requirements
offline, and he is satisfied.
> So you're saying that we should not allow pluggable URI schemes?
You have previously stated that the "URL contract" is one of the most
important "contracts" we have. I agree. However, that does not
reconcile with your desire to have allowing pluggable URL schemes.
I happen to believe that URL scheme pluggability is NOT important. We
should pick a good URL scheme (e.g., based on ShortURLs) and stick
with it. And I am quite happy to enshrine the ShortURL scheme in code,
as ActionBean annotations. The "long URL" case, as we have agreed, is
already covered. We will have to disagree on this point.
That said, as I mentioned, UrlBindingFactory has the capabilities to
allow us to add other bindings, not just those specified in the
annotations.
> I disagree. It won't give us a better request binding (as you point
> out, Stripes will
It might. Have you looked at the URLConstructor code lately? There's
more 'ifs' in those classes than a busload of wishful thinkers.
> and it won't give us backwards compatibility in the case someone is
> using something else than Default or ShortViewURLConstructors.
Our implementation choices should not be constrained by edge cases
that depart from the URL schemes that JSPWiki supports out of the box.
Our compatibility contract is with our existing, URL schemes, not
hypothetical outside ones.
That said, for those websites who choose to depart from the three
established URL schemes (short, long aka default, and shortview),
mod_rewrite is always an alternative. So too is a NON-annotation
driven approach that externalizes the URL binding definitions and
loads them up into URLBindingFactory.
> I don't think so. I think we would be shifting complexity from one
> layer to another, and removing features and introducing a faulty URL
> scheme
Indeed, this whole discussion has been about exactly that -- shifting
responsibility from a series of hard-coded classes that are inelegant
and brittle to something better. When has that stopped us before?
Two last points:
First, the whole debate about using @UrlBindings in ActionBeans is
kind of academic, because **even if we do nothing*** Stripes will use
its own default URL binding scheme. For example, let's say we have
PageActionBean, a hypothetical ActionBean that would hold our view-
page logic. Without an @UrlBinding annotation, Stripes will
automatically bind the bean to Page.action.
You have previously said that you were unhappy about this. Ok, then --
let's try and put it into a format that is more JSPWiki-like.
Second, I believe the UrlBindingFactory class has us covered for
alternative cases where users wish to use an alternative URL parsing/
generation scheme. These definitions could be externalized to a config
file, for example, and loaded into the factory at runtime via the
public method UrlBindingFactory.addBinding(beanType, binding). Stripes
will happily use these bindings too. DAV could be externalized this
way. So could other implementations. And they would all use the same
syntax, which is EL-like, very powerful, and in my view quite nice.
Imagine we had an urlbindings.properties file. We could put stuff in
it that looked like this:
PageActionBean.class=/wiki/{page}/?do={$event}
GroupActionBean.class=/groups/{group}/?do={$event}
You could add DAV bindings too, and any other bindings the user
wanted. Nice and declarative. Doing it this way would be much more
flexible than code, and would provide ways to supplement the default
URL bindings with other ones.
Think about it, wouldja? :) This could really work -- and simplify our
code base too.
Andrew
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> #5: we assume that the delimiter for spaces and sub-pages is the
> same as the one separating subpath in the URL (/)
>
> Assumption #5 is dubious IMHO, but let's assume all of the others
> are hard requirements. Even with these constraints, we can still
> use @URLBindings for inbound parsing. Here's why:
I think it is a hard requirement, for the following reasons:
1) JCR uses slashes to denote paths.
2) Slashes are the Web de-facto standard for denoting hierarchy
3) As Murray points out in his mail, the URL schema is the single
most important API contract that we have, so we should design that to
be good first, *then* figure out how to implement it. Exposing
implementation detail is not a good thing there.
4) WebDAV uses slashed to denote paths (which means that if we choose
to continue to develop the WebDAV API, it would be completely
different. At the moment, our attachments are WebDAV endpoints -
yes, you can PROPFIND on an /attach/Main/foo.jpg if you want to.)
5) We are already using slashes to denote attachments.
> DefaultURLConstructor is just the JSP path with appended
> parameters. Because every top-level JSP will have a
> stripes:useActionBean tag in it, Stripes will automatically do its
> magic resolve-bind-execute-event thing regardless, when the JSP is
> directly addressed. So if we have URLs that are of the "default"
> form, we are covered.
Yes, this is correct. And our WikiServlet covers nicely all other
URL schemes.
> As for "short form" URLs, our current URL syntax could be handled
> by the "clean URL" @URLBinding syntax quite easily. Janne, you
> might not realize this, but the clean URL format is more flexible
> than you think. It does not require an exact match; just the firrst
> part of the URL needs to match. If the remainder is a series of
> appended parameters (in normal '&' syntax), these are bound as
> normal parameters. So you do not need to specify an URLBinding that
> includes absolutely every parameter you would ever need to bind --
> just the important ones. That is exactly how short URLs work today,
> no?
Wrong. It still won't cover the subpages or attachments. Also, it
won't cover Murray's requirement.
(I've written two Stripes applications in the meantime ;-)
> So -- if we have 1) the DefaultURLConstructor covered via
> stripes:useActionBean and 2) the ShortURLConstructor covered via
> URLBindings, then by definition we also have 3)
> ShortViewURLConstructor covered. Requirement #3 (other URL schemes)
> is not met, but there is always mid_rewrite for those cases.
So you're saying that we should not allow pluggable URI schemes?
> The wildcard here is what happens with wikispaces and nested pages.
> Best case: Stripes does not care what is used as a delimiter, even
> a '/'. Worst case: Stripes does care, so we use a different
> delimiter, like a colon.
Stripes does care, and I don't think we can use anything else.
> Now, this kind of throws out Murray's particular scenario, but it
> does neatly give us, essentially, solid backwards compatibility and
> much better request binding, and great forward compatibility. We
> would still need an improved URL constructor class for the short
> URL case, which would rely on the URLBindings for instructions on
> how to make the URLs.
I disagree. It won't give us a better request binding (as you point
out, Stripes will be entirely happy to bind stuff with almost any URL
with stripes:useActionBean - and the only real problem is the "page"
parameter - everything else is a regular query string). It won't
give us forward compatibility because it cannot work with subpages,
and it won't give us backwards compatibility in the case someone is
using something else than Default or ShortViewURLConstructors.
> We would effectively be trading code for annotations. Personally, I
> think that is a good thing, because it makes it easier to create
> new ActionBeans (features!)
I don't think so. I think we would be shifting complexity from one
layer to another, and removing features and introducing a faulty URL
scheme, forcing people like Murray to use Apache as a front-end.
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Andrew Jaquith <an...@mac.com>.
Interesting thread! You guys had me at a disadvantage -- I was on a
plane from Latin America this morning, and have not been able to
respond until now.
I think I smell a resolution in the air. It is, indeed, to use Stripes
as the "backing technology" for short URLs. Doing this gets us
compatibility with all three current URLConstructors. Here's why:
First, let me state what I think I heard from Janne.
#1: we have to stay compatible with ShortURLConstructor
#2: we have to stay compatible with DefaultURLConstructor too
#3: Janne has no interest in coming up with a new scheme, but is happy
to let "others" (read: Murray) go crazy if they want to, outside of
the core distro
#4: despite restrictions 1, 2, and 3, the URL scheme needs to somehow
accommodate subpages and wiki spaces
#5: we assume that the delimiter for spaces and sub-pages is the same
as the one separating subpath in the URL (/)
Assumption #5 is dubious IMHO, but let's assume all of the others are
hard requirements. Even with these constraints, we can still use
@URLBindings for inbound parsing. Here's why:
DefaultURLConstructor is just the JSP path with appended parameters.
Because every top-level JSP will have a stripes:useActionBean tag in
it, Stripes will automatically do its magic resolve-bind-execute-event
thing regardless, when the JSP is directly addressed. So if we have
URLs that are of the "default" form, we are covered.
As for "short form" URLs, our current URL syntax could be handled by
the "clean URL" @URLBinding syntax quite easily. Janne, you might not
realize this, but the clean URL format is more flexible than you
think. It does not require an exact match; just the firrst part of the
URL needs to match. If the remainder is a series of appended
parameters (in normal '&' syntax), these are bound as normal
parameters. So you do not need to specify an URLBinding that includes
absolutely every parameter you would ever need to bind -- just the
important ones. That is exactly how short URLs work today, no?
So -- if we have 1) the DefaultURLConstructor covered via
stripes:useActionBean and 2) the ShortURLConstructor covered via
URLBindings, then by definition we also have 3)
ShortViewURLConstructor covered. Requirement #3 (other URL schemes) is
not met, but there is always mid_rewrite for those cases.
The wildcard here is what happens with wikispaces and nested pages.
Best case: Stripes does not care what is used as a delimiter, even a
'/'. Worst case: Stripes does care, so we use a different delimiter,
like a colon.
Now, this kind of throws out Murray's particular scenario, but it does
neatly give us, essentially, solid backwards compatibility and much
better request binding, and great forward compatibility. We would
still need an improved URL constructor class for the short URL case,
which would rely on the URLBindings for instructions on how to make
the URLs.
We would effectively be trading code for annotations. Personally, I
think that is a good thing, because it makes it easier to create new
ActionBeans (features!)
Andrew
On Jul 8, 2008, at 12:03 PM, Janne Jalkanen <Ja...@ecyrd.com>
wrote:
>> I'm thinking that perhaps Andrew and I might be able to fix it via
>> Stripes. I don't know how big the library is but if it's not big we
>> could possibly introduce Stripes into the mix as the backing
>> technology
>> for the ShortURLConstructor, which would ease *everyone* into the 3.0
>> path since they could begin to use the new schema for all new sites
>>
> I don't really see any way that we could use Stripes here. And
> personally, I would not use a new scheme... So it certainly
> wouldn't help my job ;-)
>
>> The 'collectionHierarchy' is in the current wiki a single token but
>> *could* be deeper. Given I don't think we'd want arbitrary depth
>> (I may be wrong) then there's only the possibility that we might
>> go from "Main" to "Main/SubMain". That shouldn't be a big problem
>> if we design the schema such that the verb is either at the very
>> end or part of the query. So "Main/edit" can only be a page reference
>> if it's "Main/edit/verb/" (e.g., "Main/edit/edit/") or
>> "Main/edit/?action=verb". This shouldn't be a problem.
>
> It is, because Stripes CleanURLs assume static paths - item #1 is
> always something, item #2 is something else, etc. Stripes cannot
> guess when a slash is a part of a page name, and when it is an
> action. The CleanURLs are nice, if you are developing an app from
> scratch. It's not so nice trying to retrofit existing URLs.
>
> This means a separate parser, and that means an URLConstructor (or
> something similar). Which again means that Stripes is nice, but I
> think this particular idea is wholly unsuited for the problem at hand.
>
>>
>>> Well, the URIs *are* already RESTful. ;-)
>>> (In fact, /Edit.jsp?page=Foo is also RESTful. Most people just
>>> like to hide the technology [jsp in this case] by using neutral
>>> URIs like /edit/Foo).
>>
>> Yes, I have an absolute, unbendable requirement that we have to hide
>> implementation details from the URLs. So if one's definition of
>> RESTful
>> includes hiding implementation details (and mine does), then this
>> is a
>> necessity. In my actual case it is a requirement.
>
> Well, you are entitled to define the words anyway you want, but
> don't expect us to adhere to the same definitions. JSPWiki is
> already RESTful in the commonly agreed definition.
>
>> etc. I'd also like to be able to do PUTs via a RESTful interface in
>> addition to the human UI so we can remotely populate a wiki from an
>> external site, for synchronization, etc.
>
> I highly recommend that you implement the Atom Publishing Protocol
> then. It's pretty much the standard these days. We have the basics
> in place, but we should really switch to a better library, since the
> current implementation does not support APP 1.0.
>
> The other possibility is to start working on the DAV interface
> (which defines all your metadata stuff in a commonly agreed language
> instead of redefining the meaning of the HTTP verb HEAD ;-). The
> DAV stuff mostly works, but it's client-specific.
>
> Both are REST.
>
> I'm not sure whether we would need a third one.
>
> /Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> I'm thinking that perhaps Andrew and I might be able to fix it via
> Stripes. I don't know how big the library is but if it's not big we
> could possibly introduce Stripes into the mix as the backing
> technology
> for the ShortURLConstructor, which would ease *everyone* into the 3.0
> path since they could begin to use the new schema for all new sites
>
I don't really see any way that we could use Stripes here. And
personally, I would not use a new scheme... So it certainly wouldn't
help my job ;-)
> The 'collectionHierarchy' is in the current wiki a single token but
> *could* be deeper. Given I don't think we'd want arbitrary depth
> (I may be wrong) then there's only the possibility that we might
> go from "Main" to "Main/SubMain". That shouldn't be a big problem
> if we design the schema such that the verb is either at the very
> end or part of the query. So "Main/edit" can only be a page reference
> if it's "Main/edit/verb/" (e.g., "Main/edit/edit/") or
> "Main/edit/?action=verb". This shouldn't be a problem.
It is, because Stripes CleanURLs assume static paths - item #1 is
always something, item #2 is something else, etc. Stripes cannot
guess when a slash is a part of a page name, and when it is an
action. The CleanURLs are nice, if you are developing an app from
scratch. It's not so nice trying to retrofit existing URLs.
This means a separate parser, and that means an URLConstructor (or
something similar). Which again means that Stripes is nice, but I
think this particular idea is wholly unsuited for the problem at hand.
>
>> Well, the URIs *are* already RESTful. ;-)
>> (In fact, /Edit.jsp?page=Foo is also RESTful. Most people just
>> like to hide the technology [jsp in this case] by using neutral
>> URIs like /edit/Foo).
>
> Yes, I have an absolute, unbendable requirement that we have to hide
> implementation details from the URLs. So if one's definition of
> RESTful
> includes hiding implementation details (and mine does), then this is a
> necessity. In my actual case it is a requirement.
Well, you are entitled to define the words anyway you want, but don't
expect us to adhere to the same definitions. JSPWiki is already
RESTful in the commonly agreed definition.
> etc. I'd also like to be able to do PUTs via a RESTful interface in
> addition to the human UI so we can remotely populate a wiki from an
> external site, for synchronization, etc.
I highly recommend that you implement the Atom Publishing Protocol
then. It's pretty much the standard these days. We have the basics
in place, but we should really switch to a better library, since the
current implementation does not support APP 1.0.
The other possibility is to start working on the DAV interface (which
defines all your metadata stuff in a commonly agreed language instead
of redefining the meaning of the HTTP verb HEAD ;-). The DAV stuff
mostly works, but it's client-specific.
Both are REST.
I'm not sure whether we would need a third one.
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>> Yes, understood. I'm thinking it might be a fourth URLConstructor scheme
>> since it won't completely replace (plug-and-play wise) any of the
>> existing schemes. And as I mentioned to Andrew, I'd like to be able to
>> literally re-use it to invoke another web service layer on top of
>> JSPWiki (for preservation, interwiki, and other potential services).
>
> If you're in a hurry, I would look into a specific URLConstructor... I
> doubt 3.0 will be ready for a long time.
Understood -- as I mentioned just a minute ago, I'd hope we could get
this developed as an add-on that would *also* work with 3.0.
>> I'm not much on hype myself, and while I do agree that the
>> ShortURLConstructor
>> is either very close to or exactly matching the URL schema I'm
>> considering,
>> there are some problems with the existing implementation *and* I believe
>> I may have a requirement to load the verb on as the latter token rather
>> than being included in the query string. I don't want to quibble over the
>> definition of RESTful either, but I may need to replace that latter URL
>
> You could fix the ShortURLConstructor ;-)
I'm thinking that perhaps Andrew and I might be able to fix it via
Stripes. I don't know how big the library is but if it's not big we
could possibly introduce Stripes into the mix as the backing technology
for the ShortURLConstructor, which would ease *everyone* into the 3.0
path since they could begin to use the new schema for all new sites
once we made the new constructor available (as option #4 potentially,
if a complete replacement of ShortURLConstructor isn't feasible or the
URL schema doesn't quite match ShortURLConstructor's, and I don't think
it does exactly).
>> ShortURLConstructor - uses path-like reference style:
>>
>> http://mywiki.com/jspwiki/wiki/Main
>> http://mywiki.com/jspwiki/wiki/Main?do=Edit
>>
>> with
>>
>> http://mywiki.com/jspwiki/wiki/Main/edit/
>
> Both of these are RESTful, with the added bonus that the latter will
> break once we have sub-pages and someone creates a page called "Main/edit".
>
> Which, BTW, is also a big problem with CleanURIs.
No, I don't think you noticed the schema design then:
baseURL collectionHierarchy [objectId] action ['?' parameters]
The 'collectionHierarchy' is in the current wiki a single token but
*could* be deeper. Given I don't think we'd want arbitrary depth
(I may be wrong) then there's only the possibility that we might
go from "Main" to "Main/SubMain". That shouldn't be a big problem
if we design the schema such that the verb is either at the very
end or part of the query. So "Main/edit" can only be a page reference
if it's "Main/edit/verb/" (e.g., "Main/edit/edit/") or
"Main/edit/?action=verb". This shouldn't be a problem.
>> Yes, certainly. We're dealing with government/corporate cooperative team
>> designing and implementing an enormous application that is entirely built
>> on this principle. There are RESTful URLs all through the application and
>> I've got a requirement to hook JSPWiki into that. It would be lovely if
>> the URLs that the user sees when using the wiki are the *same* ones (or
>> are from at least the same schema) as the ones hooking the wiki into the
>> preservation system, which is why I'm excited by Andrew's latest missive.
>
> Well, the URIs *are* already RESTful. ;-)
>
> (In fact, /Edit.jsp?page=Foo is also RESTful. Most people just like to
> hide the technology [jsp in this case] by using neutral URIs like
> /edit/Foo).
Yes, I have an absolute, unbendable requirement that we have to hide
implementation details from the URLs. So if one's definition of RESTful
includes hiding implementation details (and mine does), then this is a
necessity. In my actual case it is a requirement.
Another aspect of this I haven't mentioned is that we do want to
implement the full REST set of verbs, e.g., we want a HEAD request
(whatever it's called, doesn't matter) to deliver metadata about
a record, e.g.,
// delivers default metadata
http://mywiki.com/jspwiki/wiki/Main/meta/
// delivers METS metadata
http://mywiki.com/jspwiki/wiki/Main/meta/?schema=mets
// delivers DC-XML metadata
http://mywiki.com/jspwiki/wiki/Main/meta/?schema=dcxml
etc. I'd also like to be able to do PUTs via a RESTful interface in
addition to the human UI so we can remotely populate a wiki from an
external site, for synchronization, etc.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Yes, understood. I'm thinking it might be a fourth URLConstructor
> scheme
> since it won't completely replace (plug-and-play wise) any of the
> existing schemes. And as I mentioned to Andrew, I'd like to be able to
> literally re-use it to invoke another web service layer on top of
> JSPWiki (for preservation, interwiki, and other potential services).
If you're in a hurry, I would look into a specific URLConstructor...
I doubt 3.0 will be ready for a long time.
> I'm not much on hype myself, and while I do agree that the
> ShortURLConstructor
> is either very close to or exactly matching the URL schema I'm
> considering,
> there are some problems with the existing implementation *and* I
> believe
> I may have a requirement to load the verb on as the latter token
> rather
> than being included in the query string. I don't want to quibble
> over the
> definition of RESTful either, but I may need to replace that latter
> URL
You could fix the ShortURLConstructor ;-)
>
> ShortURLConstructor - uses path-like reference style:
>
> http://mywiki.com/jspwiki/wiki/Main
> http://mywiki.com/jspwiki/wiki/Main?do=Edit
>
> with
>
> http://mywiki.com/jspwiki/wiki/Main/edit/
Both of these are RESTful, with the added bonus that the latter will
break once we have sub-pages and someone creates a page called "Main/
edit".
Which, BTW, is also a big problem with CleanURIs.
> Yes, certainly. We're dealing with government/corporate cooperative
> team
> designing and implementing an enormous application that is entirely
> built
> on this principle. There are RESTful URLs all through the
> application and
> I've got a requirement to hook JSPWiki into that. It would be
> lovely if
> the URLs that the user sees when using the wiki are the *same* ones
> (or
> are from at least the same schema) as the ones hooking the wiki
> into the
> preservation system, which is why I'm excited by Andrew's latest
> missive.
Well, the URIs *are* already RESTful. ;-)
(In fact, /Edit.jsp?page=Foo is also RESTful. Most people just like
to hide the technology [jsp in this case] by using neutral URIs like /
edit/Foo).
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>> I have a strong requirement for a REST-ful scheme, with some
>> flexibility on the definition of REST-ful. One thing I didn't
>
> Remember that we can't break existing URL schemes. So essentially we
> are talking about replacing the current URLConstructor scheme with
> another URLConstructor scheme, which may or may not rely on Stripes
> artifacts.
Yes, understood. I'm thinking it might be a fourth URLConstructor scheme
since it won't completely replace (plug-and-play wise) any of the
existing schemes. And as I mentioned to Andrew, I'd like to be able to
literally re-use it to invoke another web service layer on top of
JSPWiki (for preservation, interwiki, and other potential services).
> IMO RESTful has become an overloaded hypeword these days. You can look
> at it this way: we already *are* RESTful. *All* applications which use
> the browser are RESTful. REST does not mean "we will not use query
> string". REST means that every resource is accessible through an unique
> link (and that it's stateless, which we mostly are anyway).
I'm not much on hype myself, and while I do agree that the ShortURLConstructor
is either very close to or exactly matching the URL schema I'm considering,
there are some problems with the existing implementation *and* I believe
I may have a requirement to load the verb on as the latter token rather
than being included in the query string. I don't want to quibble over the
definition of RESTful either, but I may need to replace that latter URL
ShortURLConstructor - uses path-like reference style:
http://mywiki.com/jspwiki/wiki/Main
http://mywiki.com/jspwiki/wiki/Main?do=Edit
with
http://mywiki.com/jspwiki/wiki/Main/edit/
(both lowercased and potentially a different choice than "edit" (it won't
be up to me though I'll have some influence).
> When it comes to the machine-accessible APIs, then REST becomes a far
> more useful paradigm (as opposed to things like XML-RPC and SOAP).
> There is no single endpoint, but you use the same kind of an API to
> access your data as with the regular browser.
Yes, certainly. We're dealing with government/corporate cooperative team
designing and implementing an enormous application that is entirely built
on this principle. There are RESTful URLs all through the application and
I've got a requirement to hook JSPWiki into that. It would be lovely if
the URLs that the user sees when using the wiki are the *same* ones (or
are from at least the same schema) as the ones hooking the wiki into the
preservation system, which is why I'm excited by Andrew's latest missive.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> I have a strong requirement for a REST-ful scheme, with some
> flexibility on the definition of REST-ful. One thing I didn't
Remember that we can't break existing URL schemes. So essentially we
are talking about replacing the current URLConstructor scheme with
another URLConstructor scheme, which may or may not rely on Stripes
artifacts.
IMO RESTful has become an overloaded hypeword these days. You can
look at it this way: we already *are* RESTful. *All* applications
which use the browser are RESTful. REST does not mean "we will not
use query string". REST means that every resource is accessible
through an unique link (and that it's stateless, which we mostly are
anyway).
When it comes to the machine-accessible APIs, then REST becomes a far
more useful paradigm (as opposed to things like XML-RPC and SOAP).
There is no single endpoint, but you use the same kind of an API to
access your data as with the regular browser.
/Janne
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
>> http://www.acme.org/wiki/pages/PageName/?action=get
>> http://www.acme.org/wiki/pages/PageName/?action=edit
>> http://www.acme.org/wiki/pages/PageName/?action=put
>> http://www.acme.org/wiki/pages/?action=search&q=term
>
> The ShortURLConstructor does just this.
>
> Unfortunately, it's not very well tested, and is known to break some
> things, like FCK and WikiWizard.
And I've never once got the ShortURLConstructor to work reliably
on any system (Apache/Tomcat or Jetty) I've used, after much time
and frustration. I don't think that's uncommon, and on looking at
the code I've not figured out what was going wrong. I like the
idea of having a front end request manager that acts as a web
service layer to the wiki, especially if it is in effect modular.
I have a strong requirement for a REST-ful scheme, with some
flexibility on the definition of REST-ful. One thing I didn't
mention (and Andrew's Stripes proposal might provide) is a
web service approach to both the JSPWiki instance *and* a
second web service that could either be a layer on top of
JSPWiki or literally a separate application that accessed the
wiki's repository. Since it needs to share the same JVM likely
a layer, and if it was able to hand requests off to JSPWiki
*or* something I've written, well, that's basically what I'm
looking for in a nutshell.
So the Stripes approach is quite exciting, really.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: REST-ful URLs [Was: url rewriting supported?]
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> http://www.acme.org/wiki/pages/PageName/?action=get
> http://www.acme.org/wiki/pages/PageName/?action=edit
> http://www.acme.org/wiki/pages/PageName/?action=put
> http://www.acme.org/wiki/pages/?action=search&q=term
The ShortURLConstructor does just this.
Unfortunately, it's not very well tested, and is known to break some
things, like FCK and WikiWizard.
/Janne
REST-ful URLs [Was: url rewriting supported?]
Posted by Murray Altheim <mu...@altheim.com>.
One of the things I've been working on (both related and unrelated to
JSPWiki) is a web service URL schema providing read and write access
to the wiki, in particular the wiki's page provider. Without going
into detail about that I thought I might at least mention the idea
of REST-fully regularizing *all* of the URLs used by JSPWiki to a
common approach, i.e. (optional components in square brackets):
baseURL collectionHierarchy [objectId] action ['?' parameters]
e.g.,
http://www.acme.org/wiki/ pages/ PageName/ get/
This would in the future permit a collection hierarchy where 'pages/'
currently exists, with 'PageName' as object ID (oid) potentially
replaced by any kind of identifier (pages may be identified by name
or by some other kind of identifier that survives across renames --
title).
http://www.acme.org/wiki/pages/PageName/get/
http://www.acme.org/wiki/pages/PageName/edit/
http://www.acme.org/wiki/pages/PageName/put/
http://www.acme.org/wiki/pages/search/?q=term
(the actual action names aren't important) or alternately, including
the action name as a parameter:
http://www.acme.org/wiki/pages/PageName/?action=get
http://www.acme.org/wiki/pages/PageName/?action=edit
http://www.acme.org/wiki/pages/PageName/?action=put
http://www.acme.org/wiki/pages/?action=search&q=term
allowing things like:
http://www.acme.org/wiki/pages/PageName/?action=get&format=html
http://www.acme.org/wiki/pages/PageName/?action=get&format=xml
http://www.acme.org/wiki/pages/PageName/?action=get&format=text
etc., with advantages and disadvantages to each.
Has there been any thought amongst other members of the team in writing
a more REST-ful URL constructor? Perhaps as the default? While I do
understand dealing with legacy issues it'd be nice to just have a simple,
REST-ful URL that just worked. It's been one of those things I've never
been able to get working consistently in JSPWiki across all
installations.
I don't have it working yet but I basically have been writing a web
service that would provide complete access to the wiki's functionality
using a schema similar to the above. The question for me is how
difficult it'd be in rewriting the JSPs to generate URLs as according
to the web service instead of the existing setting, which of course
led me to think that the whole web service is really just an alternative
URL constructor...
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
Re: url rewriting supported?
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Now, I am not trying to persuade you to use the Stripes URLBuilder.
> However, I mention it in detail to show you that it shares one
> property with what you outlined. Namely, the principle of passing
> parameters as separate arguments rather than the way we do now, as
> a monolithic blob. This is a nice departure from what we have done,
> but it's going to require us to blow up the URLConstructor class
> (as we know it) and substitute something else. Either
> SimpleURLConstructor or the Stripes alternative. I happen to like
> the Stripes URLBuilder because it has taken localization and multi-
> valued properties into account, and does not rely on "magic
> parameters" where authors would have to remember to supply an even
> number of varargs (the first arg is the param, the second is the
> value). Anyway, you might want to take a look at the source code
> for URLBuilder. :)
I don't mind getting rid of URLConstructor, since it's a complicated
thing which does not really work.
I'm not too sure on the URLBuilder as well, since it makes it hard to
just simply to "get an URL, dammit." Yes, it's flexible, but it's
also, well, clunky.
> One thing I think we should look carefully at is whether we should
> keep the getURL() functions onto the WikiContext (aka the
> ActionBean) or move it elsewhere. My feeling is that we should
> deprecate WikiContext-level getURL() type methods and move them to
> the ActionBeanContext, which is associated with each ActionBean.
> That's where all of the HTTP-related stuff is, and I would rather
> keep the ActionBeans focused on functionality (bean properties and
> events) rather than the HTTP-related aspects of how they are
> presented. WikiContext.getURL() will be around for a while (for
> backwards compatibility reasons) but it should delegate to
> WikiActionBeanContext.getURL(). Same for WikiContext.getHttpRequest
> (), which should delegate to ActionBean.getRequest().
Did you take a look at the new API proposal in SVN? I think we
should build a good API library first, so that we can have more
freedom in building our internal core.
Note that it currently has no reference to Stripes or, well, any
other library.
>> Example: in my local builds each ActionBean has an annotation
>> called @URLBinding that says how Stripes should map the 'bean to
>> URLs. For example ViewActionBean's URLBinding is "/Wiki.action".
>> The top-level JSP is easily calculated by chopping off .action and
>> attaching ".jsp". Thus: Wiki.jsp. The content page is *generally*
>> the top-level JSP name plus "Content". So -- that's the rule. Look
>> up the URLBinding, chop off .action, and attach the suffix. "/
>> WikiContent.jsp" would be the default by convention. (Except that
>> Wiki.jsp's content page is PageContent.jsp... so for ContentTag
>> you tell it to use PageContent.jsp.)
Hm. There's one problem with Stripes which I don't like and it's the
fact that it muddles the URLs. If you enter with Wiki.jsp - then you
e.g. run validation on a form, you end up on Wiki.action.
This has the problem that then when someone grabs the URL and sends
it via email, someone else is going to end up with a non-functional URL.
So I would very much like to try and avoid using the Stripes-specific
URLs for *anything*. Relying on any particular Stripes-generated
URLs will also make us essentially stuck on Stripes, too.
> Pulling back from the detail, though, it is clear that certain
> things are going to break. But maybe less than we thought. My first
> attempt at Stripes integration made no attempt to be backwards
> compatible, and indeed, I made it deliberately incompatible with
> those features I did not like (e.g. URLConstructors, Commands).
> That was clearly too ambitious. My approach now is to keep as much
> compatibility as possible but aggressively deprecate methods or
> fields where the alternatives are better. WikiContext request
> contexts are one example.
Commands we can get rid of, yuck. They should absolutely be replaced
by ActionBeans.
> In my copious free time, I have been taking another whack at 3.0.
> The primary incompatibilities are the removal of the WikiContext
> contructor (use a factory instead) and the related setRequestContext
> () method. In fact, if it is not too late, I would not mind
> removing the WikiContext constructor NOW, in 2.8, and forcing the
> use of WikiEngine.createContext(). That's only a few cases
> (15-20?), and there is little/no exposure in the JSPs.
I wouldn't, since it's the officially promoted way to e.g. use the
renderer engine in embedding systems. We can't break that one until
3.0.
> The other major difficulty is the historical "overloading" of
> WikiContext to include non-page-related activities like groups and
> user maintenance. This is a little harder to tackle, but it should
> only affect about 30-40 places in the code.
The big problem is that WikiContext is a part of our official API, so
we can't remove any of that stuff.
But let's work on the API in the SVN - we still have time.
/Janne
Re: url rewriting supported?
Posted by Andrew Jaquith <an...@mac.com>.
> Two problems: regexps are insanely slow. When doing URL rewrites on
> something this link-intensive, you want to start caching the HTML.
> Which in turn will play havoc with the plugin code generation.
> Currently one of the biggest timeusers (if not the biggest) is the
> DefaultURLConstructor.
Regexp's are slow, no question. But remember that you probably won't
need them unless you are actually transforming URLs into something
that is NOT the default case. The defaults are (and I suspect will
continue to be) URLs that look like this:
/[webapp]/Wiki.jsp?page=Foo&version=2
The key is making the default scheme nice and fast. If you wanted to
use [a different URL constructor|a filter with regexps], you could do
that separately and pay the requisite penalty.
>
> The other problem is that I think some of our template/skin
> generation stuff might break if the context is lost...
By "context" I assume you mean "wiki context", as in WikiContext.EDIT?
As much as I'd like to do away with those, and move towards strong
typing (prefer UserPreferencesActionBean.class to WikiContext.PREFS),
the legacy contexts will be with us for a while.
At present, I am working on making my earlier 3.0/Stripes integration
as backwards-compatible as possible. Example: I have a custom
annotation called @WikiRequestContext that is class-level, and permits
class authors to annotate the wiki request context string ("edit",
"prefs") etc it has. It should work quite nicely -- all we do is
slightly retrofit WikiContext so that WikiContext.PREFS gets its value
from an annotation lookup rather than a text string
(UserPreferencesActionBean
.getAnnotation(WikiRequestContext.class).value()). It pushes
responsibility for declaring stuff like this to the class itself. It
also makes it easier for authors who want to write their own
ActionBeans (no more hacking the Command classes...).
> However, Java5 varargs I think give us a nice exit. How about
>
> WikiContext.generateURL( String content, String param1, String
> value1, ... )
>
> with
>
> PARAM_PAGE = "page"
> PARAM_VERSION = "version"
>
> and the JSP param could be "Wiki.jsp", or "rss.jsp" or "attach" or
> "scripts/jspwiki.js" - direct servlet/JSP/resource names. E.g.
>
> ...
> wikiContext.generateURL( "Wiki.jsp", PARAM_PAGE, newPage,
> PARAM_VERSION, 1, "skin", "raw" );
> ...
>
> We could then have a SimpleURLConstructor (which just attaches the
> params one after the other), a RegexpURLConstructor (which extends
> the SimpleURLConstructor and just passes them through a regexp
> list), and so on. I like the fact that code can be optimized in
> these cases quite a lot, but rules cannot.
Indeed. You might want to take a look at the Stripes URLBuilder class.
You instantiate it with a locale first, and either a path or an
ActionBean class:
builder = new URLBuilder(locale, "/Wiki.jsp" );
or
builder = new URLBuilder(locale, ViewActionBean.class );
Then, you add parameters either one-by-one or as an array:
builder.addParameter( "page", "Foo" );
Note that the second argument is a vararg, because parameters can be
multi-valued.
After that, the method build() returns the correctly formatted and
encoded String.
Now, I am not trying to persuade you to use the Stripes URLBuilder.
However, I mention it in detail to show you that it shares one
property with what you outlined. Namely, the principle of passing
parameters as separate arguments rather than the way we do now, as a
monolithic blob. This is a nice departure from what we have done, but
it's going to require us to blow up the URLConstructor class (as we
know it) and substitute something else. Either SimpleURLConstructor or
the Stripes alternative. I happen to like the Stripes URLBuilder
because it has taken localization and multi-valued properties into
account, and does not rely on "magic parameters" where authors would
have to remember to supply an even number of varargs (the first arg is
the param, the second is the value). Anyway, you might want to take a
look at the source code for URLBuilder. :)
One thing I think we should look carefully at is whether we should
keep the getURL() functions onto the WikiContext (aka the ActionBean)
or move it elsewhere. My feeling is that we should deprecate
WikiContext-level getURL() type methods and move them to the
ActionBeanContext, which is associated with each ActionBean. That's
where all of the HTTP-related stuff is, and I would rather keep the
ActionBeans focused on functionality (bean properties and events)
rather than the HTTP-related aspects of how they are presented.
WikiContext.getURL() will be around for a while (for backwards
compatibility reasons) but it should delegate to
WikiActionBeanContext.getURL(). Same for WikiContext.getHttpRequest(),
which should delegate to ActionBean.getRequest().
(In case you were wondering: the WikiActionBeanFactory, and the
StripesFilter, both guarantee that every ActionBean [WikiContext] has
an associated ActionBeanContext...)
> I don't think we really need to carry the notion of the request
> context that much further, as it's far clearer to point directly to
> the JSP or resource instead of an abstract name. Unfortunately it
> means that things like the ContentTag will break. But then again,
> the stripes-based UI is probably going to break it anyway.
I agree, mostly. The act of moving functions that are grouped together
into ActionBeans means that we are better off simply specifying the
bean itself, or a class reference to it, instead of the String (the
request context). Using strong typing (the class) rather than strings
means we can do other things too. For example, the ActionBean could
have an annotation that names the content template JSP. Or (my
preference) it could be calculated as a default value, and you use
page markup or annotations for those cases where the defaults don't
work.
Example: in my local builds each ActionBean has an annotation called
@URLBinding that says how Stripes should map the 'bean to URLs. For
example ViewActionBean's URLBinding is "/Wiki.action". The top-level
JSP is easily calculated by chopping off .action and attaching ".jsp".
Thus: Wiki.jsp. The content page is *generally* the top-level JSP name
plus "Content". So -- that's the rule. Look up the URLBinding, chop
off .action, and attach the suffix. "/WikiContent.jsp" would be the
default by convention. (Except that Wiki.jsp's content page is
PageContent.jsp... so for ContentTag you tell it to use
PageContent.jsp.)
Pulling back from the detail, though, it is clear that certain things
are going to break. But maybe less than we thought. My first attempt
at Stripes integration made no attempt to be backwards compatible, and
indeed, I made it deliberately incompatible with those features I did
not like (e.g. URLConstructors, Commands). That was clearly too
ambitious. My approach now is to keep as much compatibility as
possible but aggressively deprecate methods or fields where the
alternatives are better. WikiContext request contexts are one example.
In my copious free time, I have been taking another whack at 3.0. The
primary incompatibilities are the removal of the WikiContext
contructor (use a factory instead) and the related setRequestContext()
method. In fact, if it is not too late, I would not mind removing the
WikiContext constructor NOW, in 2.8, and forcing the use of
WikiEngine.createContext(). That's only a few cases (15-20?), and
there is little/no exposure in the JSPs.
The other major difficulty is the historical "overloading" of
WikiContext to include non-page-related activities like groups and
user maintenance. This is a little harder to tackle, but it should
only affect about 30-40 places in the code.
Again, in the short term the goal is backwards compatibility, even if
we carry forward some things that we will deprecate. My previous
attempt modified about 300 classes; I think I can get that down to
about 50. JSPs are the wildcard here, but here too there are some
steps we can take to (hopefully) limit the changes to about 20 JSPs or
so, and keep them relatively minor also.
Janne, sorry for the ramble... I have had lots of "plane time" lately,
and have been trying to get my 3.0 builds re-synced with the 2.8
branch. Seemed like a good time to bring you up to date.
Andrew
Re: url rewriting supported?
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
>> I'm still opposed to the idea because of the context loss
>> involved. URL rewriting *after* the HTML translation is done
>> means that e.g. preformatted areas would also get all of their
>> URLs rewritten.
>
> Just wanted to ask you more about what you meant by this. I think
> what you were implying is that we would somehow wrap the response,
> capture all of its output, and do replacements on the whole
> response. That is not what I meant... I was thinking of something
> simpler.
Yes, that's exactly what I was thinking...
> The advantage of encoding the URLs via the response is that it is
> would be nice and safe for classes that need to generate URLs.
> Classes that generate URLs would only need to generate ones that
> looked "normal" (making sure they called encodeURL of course)
> rather than hieroglyphic ones. (E.g., a rendering class would
> generate /Wiki.jsp?page=Foo rather than %b%p=Foo or whatever it is
> now.). That's an easier contract to adhere to than our current scheme.
Ah, I see.
> The other advantage is that it externalizes the URL-generation
> mechanism in a way that allows us to plug in creative ways of
> rewriting URLs (and un-rewriting them coming in as requests). This
> is where URLRewrite comes in -- it could provide everything that
> ShortURLConstructor does, but all through rules rather than *code*.
> And JSPWiki itself would not have any awareness that the URLs were
> anything other than regula
Two problems: regexps are insanely slow. When doing URL rewrites on
something this link-intensive, you want to start caching the HTML.
Which in turn will play havoc with the plugin code generation.
Currently one of the biggest timeusers (if not the biggest) is the
DefaultURLConstructor.
The other problem is that I think some of our template/skin
generation stuff might break if the context is lost...
However, Java5 varargs I think give us a nice exit. How about
WikiContext.generateURL( String content, String param1, String
value1, ... )
with
PARAM_PAGE = "page"
PARAM_VERSION = "version"
and the JSP param could be "Wiki.jsp", or "rss.jsp" or "attach" or
"scripts/jspwiki.js" - direct servlet/JSP/resource names. E.g.
...
wikiContext.generateURL( "Wiki.jsp", PARAM_PAGE, newPage,
PARAM_VERSION, 1, "skin", "raw" );
...
We could then have a SimpleURLConstructor (which just attaches the
params one after the other), a RegexpURLConstructor (which extends
the SimpleURLConstructor and just passes them through a regexp list),
and so on. I like the fact that code can be optimized in these cases
quite a lot, but rules cannot.
I don't think we really need to carry the notion of the request
context that much further, as it's far clearer to point directly to
the JSP or resource instead of an abstract name. Unfortunately it
means that things like the ContentTag will break. But then again,
the stripes-based UI is probably going to break it anyway.
/Janne
Re: url rewriting supported?
Posted by Andrew Jaquith <an...@mac.com>.
Janne --
> I'm still opposed to the idea because of the context loss involved.
> URL rewriting *after* the HTML translation is done means that e.g.
> preformatted areas would also get all of their URLs rewritten.
Just wanted to ask you more about what you meant by this. I think what
you were implying is that we would somehow wrap the response, capture
all of its output, and do replacements on the whole response. That is
not what I meant... I was thinking of something simpler.
In the case of URLRewrite, for it to work properly, you just encode
the URLs when you need to. All you need to do is make sure you have a
response object available, for calling response.encodeURL() on a
particular URL. If you don't call encodeURL(), nothing happens to it.
So I don't think preformatted areas would have their URLs re-written,
because while in a preformatted area you would not call
response.encodeURL().
Or did I misinterpret what you meant?
The advantage of encoding the URLs via the response is that it is
would be nice and safe for classes that need to generate URLs. Classes
that generate URLs would only need to generate ones that looked
"normal" (making sure they called encodeURL of course) rather than
hieroglyphic ones. (E.g., a rendering class would generate /Wiki.jsp?
page=Foo rather than %b%p=Foo or whatever it is now.). That's an
easier contract to adhere to than our current scheme.
The other advantage is that it externalizes the URL-generation
mechanism in a way that allows us to plug in creative ways of
rewriting URLs (and un-rewriting them coming in as requests). This is
where URLRewrite comes in -- it could provide everything that
ShortURLConstructor does, but all through rules rather than *code*.
And JSPWiki itself would not have any awareness that the URLs were
anything other than regular URLs.
Re: url rewriting supported?
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
On Jun 19, 2008, at 22:39 , Andrew Jaquith wrote:
> Simon --
>
> I've been gently tweaking Janne from time to time about
> externalizing the URL constructors in a similar manner to what you
> describe, although the use I had in mind wasn't related to session
> IDs.
I'm still opposed to the idea because of the context loss involved.
URL rewriting *after* the HTML translation is done means that e.g.
preformatted areas would also get all of their URLs rewritten.
Though I have to admit that the current URLConstructors are kind of
messy, so rewriting them to be clearer might be a better solution.
(Yes, it's also possible to write something like <a href="XXX-MAGIC/
Wiki.jsp"> and then rewrite those magic markers, BUT this means that
the output from the MarkupTranslator would no longer be functional,
which will make the life of the embedders more complicated. I would
much rather go through a bit of extra complexity in our code to make
sure the developers don't have to worry about some hidden magic
effects which are caused by complex interaction of thingamalingies
which you "just have to know". We've got enough of those already ;-)
/Janne
Re: url rewriting supported?
Posted by Andrew Jaquith <an...@mac.com>.
Simon --
I've been gently tweaking Janne from time to time about externalizing
the URL constructors in a similar manner to what you describe,
although the use I had in mind wasn't related to session IDs.
Something like http://tuckey.org/urlrewrite/ would do nicely, and
would certainly allow us to implement custom URL schemes without
having JSPWiki needing to be aware of how the URLs were made. The
trade-off, as always, is memory and some performance.
For 3.0, this might happen, or might not.
Andrew
On Jun 19, 2008, at 3:41 AM, Simon Kitching wrote:
> Olaf Kock schrieb:
>> Simon Kitching schrieb:
>>
>>> By the way, I don't see cookies as a lot more secure. The cookie
>>> text is
>>> also sent in plain text in both the request and response bodies.
>>> There
>>> aren't many cases where someone can intercept the url but not the
>>> cookies. But thanks for the reference to OWASP; I'll have a look
>>> at what
>>> they say about that.
>>>
>>
>> Hi,
>>
>> I do get your point with the dev environment and logging in multiple
>> times. However, even though http transfer is the same for urls and
>> cookies the url may be transferred for referred images and links to
>> other sites as the referrer, e.g. the url of a page that a link was
>> clicked on.
>>
>> This is hard to get around correctly and the reason for this setup
>> to be
>> so unpopular securitywise.
>>
> That's a good point for a general-purpose wiki tool. Thanks for
> pointing
> that out.
>
> It's not quite so relevant for the specific use we are making of
> JspWiki, and not at all an issue for development/testing. But I agree
> that *most* people won't be using jspwiki the way we do.
>
> Just for the record (in case someone else wants to do this), enabling
> "url rewriting" support seems to be fairly easy. I have:
> * added a servlet filter which stores the HttpServletResponse in a
> thread-local
> * implemented a custom URLConstructor (subclassing
> DefaultURLConstructor) which overrides the makeURL method to fetch the
> HttpServletResponse from that thread-local and invoke encodeURL on it.
> Note that this method is also called during jspwiki startup, so a null
> HttpServletResponse needs to be ignored.
>
> I'm not sure if this approach will fix 100% of the urls that JspWiki
> generates, but it is certainly enough to get things generally
> working in
> our test environment (so far).
>
> Regards,
> Simon
>
Re: url rewriting supported?
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
>
> Just for the record (in case someone else wants to do this), enabling
> "url rewriting" support seems to be fairly easy. I have:
> * added a servlet filter which stores the HttpServletResponse in a
> thread-local
> * implemented a custom URLConstructor (subclassing
> DefaultURLConstructor) which overrides the makeURL method to fetch the
> HttpServletResponse from that thread-local and invoke encodeURL on it.
> Note that this method is also called during jspwiki startup, so a null
> HttpServletResponse needs to be ignored.
>
> I'm not sure if this approach will fix 100% of the urls that JspWiki
> generates, but it is certainly enough to get things generally
> working in
> our test environment (so far).
This sounds fairly functional. Can't see offhand what could possibly
break.
/Janne
Re: url rewriting supported?
Posted by Simon Kitching <sk...@ops.co.at>.
Olaf Kock schrieb:
> Simon Kitching schrieb:
>
>> By the way, I don't see cookies as a lot more secure. The cookie text is
>> also sent in plain text in both the request and response bodies. There
>> aren't many cases where someone can intercept the url but not the
>> cookies. But thanks for the reference to OWASP; I'll have a look at what
>> they say about that.
>>
>
> Hi,
>
> I do get your point with the dev environment and logging in multiple
> times. However, even though http transfer is the same for urls and
> cookies the url may be transferred for referred images and links to
> other sites as the referrer, e.g. the url of a page that a link was
> clicked on.
>
> This is hard to get around correctly and the reason for this setup to be
> so unpopular securitywise.
>
That's a good point for a general-purpose wiki tool. Thanks for pointing
that out.
It's not quite so relevant for the specific use we are making of
JspWiki, and not at all an issue for development/testing. But I agree
that *most* people won't be using jspwiki the way we do.
Just for the record (in case someone else wants to do this), enabling
"url rewriting" support seems to be fairly easy. I have:
* added a servlet filter which stores the HttpServletResponse in a
thread-local
* implemented a custom URLConstructor (subclassing
DefaultURLConstructor) which overrides the makeURL method to fetch the
HttpServletResponse from that thread-local and invoke encodeURL on it.
Note that this method is also called during jspwiki startup, so a null
HttpServletResponse needs to be ignored.
I'm not sure if this approach will fix 100% of the urls that JspWiki
generates, but it is certainly enough to get things generally working in
our test environment (so far).
Regards,
Simon
Re: url rewriting supported?
Posted by Olaf Kock <ok...@abstrakt.de>.
Simon Kitching schrieb:
> By the way, I don't see cookies as a lot more secure. The cookie text is
> also sent in plain text in both the request and response bodies. There
> aren't many cases where someone can intercept the url but not the
> cookies. But thanks for the reference to OWASP; I'll have a look at what
> they say about that.
Hi,
I do get your point with the dev environment and logging in multiple
times. However, even though http transfer is the same for urls and
cookies the url may be transferred for referred images and links to
other sites as the referrer, e.g. the url of a page that a link was
clicked on.
This is hard to get around correctly and the reason for this setup to be
so unpopular securitywise.
Cheers,
Olaf
Re: url rewriting supported?
Posted by Simon Kitching <sk...@ops.co.at>.
Hi Andrew,
Many thanks for the quick answer.
Yes I did mean encoding the session id in the url
("http://host/foo.jsp;jsessionid=123?page=Main").
We want to disable cookies in our dev environment so that we can log
into the same app multiple times from the same browser; this makes
testing some things a lot easier. Firefox shares cookies between windows
unless you go to a lot of effort (setting up separate profiles). Note
that in the setup here, there is a large existing webapp with an
embedded jspwiki engine to serve the help pages; disabling a dev/test
feature in order to support the (small) help engine feature hasn't been
terribly popular.
I'm working on enabling this in JSPWiki anyway, but won't bother
submitting the patches here.
By the way, I don't see cookies as a lot more secure. The cookie text is
also sent in plain text in both the request and response bodies. There
aren't many cases where someone can intercept the url but not the
cookies. But thanks for the reference to OWASP; I'll have a look at what
they say about that.
Regards,
Simon
Andrew Jaquith schrieb:
> Putting the session ID in the URL (which is I think what you are
> asking about) is a fairly severe security risk. Cloning the session
> becomes trivial if the URL is obtained.
>
> I know that in certain locales (Germany, for example), it is believed
> that cookies represent an invasion of privacy. But, perversely,
> banning cookies actually decreases the overall level security for
> webapps because the session ID is now exposed in the URL. For this
> reason, the practice of adding session IDs to webapp URLs has always
> been discouraged by best-practice organizations such as OWASP.
>
> Janne's comment from 2006, I expect, still holds. We would encourage
> anyone who wishes to eliminate cookies -- in spite of best-practice
> advice from the security community -- to write their own patches. But
> it is extremely unlikely that JSPWiki will ever incorporate a "no
> cookie" (URL rewriting) feature.
>
> Andrew
>
> On Jun 18, 2008, at 10:20 AM, Simon Kitching wrote:
>
>> Hi,
>>
>> This email from 2006 says that "url rewriting" (ie having sessions
>> without cookies) is not supported by JSPWiki. Is this still true for
>> later releases?
>> http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004
>>
>> Thanks,
>> Simon
>>
>
Re: url rewriting supported?
Posted by Andrew Jaquith <an...@mac.com>.
Putting the session ID in the URL (which is I think what you are
asking about) is a fairly severe security risk. Cloning the session
becomes trivial if the URL is obtained.
I know that in certain locales (Germany, for example), it is believed
that cookies represent an invasion of privacy. But, perversely,
banning cookies actually decreases the overall level security for
webapps because the session ID is now exposed in the URL. For this
reason, the practice of adding session IDs to webapp URLs has always
been discouraged by best-practice organizations such as OWASP.
Janne's comment from 2006, I expect, still holds. We would encourage
anyone who wishes to eliminate cookies -- in spite of best-practice
advice from the security community -- to write their own patches. But
it is extremely unlikely that JSPWiki will ever incorporate a "no
cookie" (URL rewriting) feature.
Andrew
On Jun 18, 2008, at 10:20 AM, Simon Kitching wrote:
> Hi,
>
> This email from 2006 says that "url rewriting" (ie having sessions
> without cookies) is not supported by JSPWiki. Is this still true for
> later releases?
> http://www.nabble.com/URL-Rewriting-to6040752.html#a6042004
>
> Thanks,
> Simon
>