WSRP Interop Issues

Issue No.:

Applies to version:

Issue Description

Proposed Resolution

Issue No.: 1

Applies to version: WSRP spec 1.0

Issue Description

Our current guest user convention is described as follows:

  1. Consumer passes wsrp:minimal as the userContextKey
  2. Consumer sets user category to wsrp:minimal

However this has some quirks:

  1. Producers are not required to provide any categories in the ServiceDescription.userCategoryDescriptions
  2. Consumers are not allowed to specify any userCategory not defined in the Producer's ServiceDescription
  3. 1+2=3. If the Producer does not define any user category being supported, the convention we've chosen prevents the Consumer to specify an anonymous user simply because it would contradict either 2. or the convention -> no way out for the Consumer.

Comments from Mike:

  1. Passing null as the user context still exists and still means the consumer doesn't know who the user is -- i.e. this is an anonymous/guest user however representing it this way means the consumer can't pass any user category information.
  2. If a consumer supports "guest" categories they must use an alternative way to represent the guest user. To do this they pass a userContext of "wsrp:minimal"
  3. Consumers can only map consumer categories that a guest is in to wsrp:minimal. It can only do this if the producer actually says it uses/cares about wsrp:minimal.
  4. In an such a conducive environment the consumer needs a way to communicate/distinguish between a guest that isn't mapped to wsrp:minimal and a guest that is. I.e. the user of the consumer might have decided that guest categories shouldn't be mapped to anything in this producer [not "wsrp:minimal"] and hence wants to communicate that its guests run with no user cateory [i.e. NOT wsrp:minimal] I.e. in the end we said wsrp:minimal is the only valid user category for aguest user because such a beast is a special case and we had no way todistinguish [allow a producer to declare] which user categories apply tothis special case vs the typical "all user case". However, once we saidthere was a way to have a meaningful user category for a guest then weneeded a way to distinguish between a consumer that says its guest shouldhave that user category vs. the absence of that category.

Comments from Richard:

  1. agreed
  2. agreed, we've choosen the userContextKey for that purpose
  3. why only to wsrp:minimal? couldn't the producer also define a guest user catgegory "guest" and expose it in its service description. In that case the consumer could map his guest categories to the producer's guest category? Isn't it just a special case that we assume that a guest is such a special thing that it could only be assigned a "low" category like wsrp:minimal? (This also prereqs the producer to declare wsrp:minimal as supported). Can't the producer also do some kind of implicit internal) mapping if it sees a guest user, espacially when we talk about case 1. This is what we mandate in the spec.
  4. OK, could be a use case. But what would be the userContext then? null or userContextKey=wsrp:minimal + userCategory=null. If I understood your intent in 2. correctly, then the latter option would be appropriate, or?

I think in general we agree and there are only nuances in the interpretation. To express a guest user where the consumer doesn't care about assigning a category we're perfectly done with 1. If a consumer want to assign a category to an end user we need userContextKey=wsrp:minimal + category. I really don't see why we limit this to just wsrp:minimal. This prereqs the producer to a) support it and b) to have the same interpretation of it. But producers could also be free to have a special guest category (like you proposed it for consumers) and would like consumers to assert it in that case. Also it contradicts the first case. On the producer side we have to deal with two kinds of guest users then. If the consumer passes userContext = null then the producer should map it to some category if it supports one (that's what we mandate in the spec) - this category could be guest. If the consumer passes userContext != null + userContextKey=wsrp:minimal, etc. then the producer would be enforced to map this user to wsrp:minimal although it might want it to be guest. Therefor I wouldn't restrict the userCategory to just wsrp:minimal. If this is the only allowed assertion then it would be redundant anyway? userContextKey=wsrp:minimal means guest, if passed the producer could also assume wsrp:minimal category in that case.

The basic questions seems here if wsrp:minimal keyed users are only allowed to be asserted to userCategory=wsrp:minimal. And if so if we need the distinction between userContext=null and userContext!=null + the above convention.

Proposed Resolution

Issue No.: 2

Applies to version: WSRP spec 1.0

Issue Description

Assume the Consumer to pass a URL-Template that contains javascript.

From the spec point of view this should be perfectly legal.

renderTemplate="javascript:buildURL('{wsrp-navigationalState}','{wsrp-mode}',.....)"

now assume some markup of the portlet like this:

<a href="javascript:doSomeThing('PortletURL.toString()')> link </a>

Here (a JSR168 example) the portlet markup uses some function to calculate

the final URL, like in the JSR168 spec the URL doesn't need to be a real

URL here (the same applies for our URLs in templates).

So the result may be that we get nested javascript functions, which doesn't

work.

The same applies to rewriting. A portlet might generate some markup

containing javascript and the consumer also uses javascript after the

rewriting process to calculate the resulting URL.

In both cases we have to deal with nested script functions, which are

forbidden.

The same problem should occur in JSR168 portlets/container URL handling.

There may be various solutions for this:

- forbid the use of javascript in URL generation on either side (we might

kill a lot of implementations with this?), i.e. do not allow portlets to

embed the result of a PortletURL.toString-like method in java script, or

disallow portlet to use javascript in URL generation, or prevent

containers/consumers to use java script in URL generation???

- have some nice means to circumvent javascript nesting (javascript helper

methods?)

- limit/restrict/explain the usage of javascript in the domain of URL

generation in the specs?

Do we feel this is a problem? If yes how do we intend to solve it.

If no, why isn’t that a problem?

Proposed Resolution