Re: Evaluating sling

2011-01-05 Thread Alexander Klimetschek
On 05.01.11 14:12, "Markus Joschko"  wrote:
>But, when I understand the documentation of the PostServlet correctly
>you have to explicitely
>add an operation parameter to trigger the extension. Can I also
>validate without relying on the client?
>Otherwise the data can get into the repository unvalidated if the
>parameter is forgotten or omitted.

A custom SlingPostProcessor runs after the post servlet has run the
respective post operation, so it works for all operations.

>I wanted to know whether the filter knows enough about an incoming
>request and if the currentNode object
>is available to the filter. So the filter can validate and set request
>attributes which can further be processed by the template.

Yes, the filter gets the SlingHttpServletRequest object (you need to cast
the (Http)ServletRequest object). Then you have access to the Resource of
the current request:

Resource res = slingRequest.getResource();

To get the node, you need to use the adapt mechanism (the currentNode in
JSPs/ESPs is only one of the variables preset in the script engines):

Node node = res.adaptTo(Node.class);

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel






Re: Evaluating sling

2011-01-05 Thread Markus Joschko
> On 05.01.11 13:02, "Markus Joschko"  wrote:
>>That's for the input side. I am also interested in the output
>>verification.
>>If I can't rely on my data having a certain format, I need to check
>>every property before accessing it.
>
> I don't understand: if you do validate on input and/or use node types to
> enforce a certain schema in your repository, why do you want to validate
> it on output again?

Point taken.
But, when I understand the documentation of the PostServlet correctly
you have to explicitely
add an operation parameter to trigger the extension. Can I also
validate without relying on the client?
Otherwise the data can get into the repository unvalidated if the
parameter is forgotten or omitted.

> For output, a servlet filter (we are talking about plain standard javax
> servlet filters here!) would need to parse the html/response format
> created by your JSPs, which is probably a bit too complex ;-)

OK, I might have phrased that incorrectly.
I wanted to know whether the filter knows enough about an incoming
request and if the currentNode object
is available to the filter. So the filter can validate and set request
attributes which can further be processed by the template.

Regards,
 Markus


Re: Evaluating sling

2011-01-05 Thread Carsten Ziegeler
Markus Joschko  wrote
>>> That makes me want to have a controller to validate my data against my
>>> model and only pass the verified data to the view to render it ;-)
>>> Can filters be used for that task?
>>
>> You could use filters or you could also use the SlingPostProcessor
>> concept. Handling this in a filter is more general as it would cover all
>> write operations not only those done through the default Sling post
>> servlet (you can write your own post servlets for example)
> 
> That's for the input side. I am also interested in the output verification.
> If I can't rely on my data having a certain format, I need to check
> every property before accessing it.
> I can do it in my view/template/script as it is done in the
> options.esp from slingbucks
>   // If field has a jcr:title property, we can use it.
> if(f["jcr:title"]) {   ...
> 
> or I check this before I pass the node/type/object to the
> view/template to render it.
> I'd prefer the later one to keep the template clean. Can this check be
> done in a filter?
> 
> I am not talking about checking just a single property but instead
> verifying that the data that I load from the repository is
> representing
> the type that I expect:
> 
> title,text,email = blog comment object that I can render in my view
> email, picture = something is wrong here. My view can't handle this
> one -> error page
> 
Ok, I guess the simplest solution for you is to create data objects
for your model and support the adaptable feature of Sling. You can then
just adapt the resource to your data object and call a validate method
on the object.
You can use the same classes for validating the input through a post
processor.

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org


Re: Evaluating sling

2011-01-05 Thread Alexander Klimetschek
On 05.01.11 13:02, "Markus Joschko"  wrote:
>That's for the input side. I am also interested in the output
>verification.
>If I can't rely on my data having a certain format, I need to check
>every property before accessing it.

I don't understand: if you do validate on input and/or use node types to
enforce a certain schema in your repository, why do you want to validate
it on output again?

If you have a model with more "relaxed" constraints, I agree, you want to
have some basic validation of the content. But I think this is the domain
of the application. A different application/template etc. might have a
slightly different view on the data. To do that, wrappers around Node or
Resource are what is IMHO typically used. You still get access to the
unstructured node, but you also can provide more complex, validating
getter-methods to use in your JSP templates.

And as I said, it is easy with JCR to for example read a long from a
property accidentally stored as string (see [1] and [2]).

>I can do it in my view/template/script as it is done in the
>options.esp from slingbucks
>  // If field has a jcr:title property, we can use it.
>if(f["jcr:title"]) {   ...
>
>or I check this before I pass the node/type/object to the
>view/template to render it.
>I'd prefer the later one to keep the template clean. Can this check be
>done in a filter?

For output, a servlet filter (we are talking about plain standard javax
servlet filters here!) would need to parse the html/response format
created by your JSPs, which is probably a bit too complex ;-)

>I am not talking about checking just a single property but instead
>verifying that the data that I load from the repository is
>representing
>the type that I expect:
>
>title,text,email = blog comment object that I can render in my view
>email, picture = something is wrong here. My view can't handle this
>one -> error page

In Sling, you have the sling:resourceType that defines all the rendering.
It is a bit like a more flexible node type. Sling will resolve the right
JSP for a given resource type, so inside that JSP you can expect a certain
structure, if you otherwise ensure that these are properly created.

But in most cases the flexibility I was talking about is about adding new
properties (in future versions or for other apps), without having to
change your schema. This won't affect existing renderers (e.g. a JSP) at
all, if they just access the properties they expect and know.

Finally, from a general standpoint, it is a good practice to show as much
as possible instead of throwing an error at the user. So in your example
above you could at least show the email and have some default values for
the missing title and text, for example.

[1] 
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#PropertyTypeConver
sion
[2] http://www.day.com/specs/jcr/1.0/6.2.6_Property_Type_Conversion.html

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel






Re: Evaluating sling

2011-01-05 Thread Markus Joschko
>> That makes me want to have a controller to validate my data against my
>> model and only pass the verified data to the view to render it ;-)
>> Can filters be used for that task?
>
> You could use filters or you could also use the SlingPostProcessor
> concept. Handling this in a filter is more general as it would cover all
> write operations not only those done through the default Sling post
> servlet (you can write your own post servlets for example)

That's for the input side. I am also interested in the output verification.
If I can't rely on my data having a certain format, I need to check
every property before accessing it.
I can do it in my view/template/script as it is done in the
options.esp from slingbucks
  // If field has a jcr:title property, we can use it.
if(f["jcr:title"]) {   ...

or I check this before I pass the node/type/object to the
view/template to render it.
I'd prefer the later one to keep the template clean. Can this check be
done in a filter?

I am not talking about checking just a single property but instead
verifying that the data that I load from the repository is
representing
the type that I expect:

title,text,email = blog comment object that I can render in my view
email, picture = something is wrong here. My view can't handle this
one -> error page

Regards,
 Markus


Re: Evaluating sling

2011-01-05 Thread Carsten Ziegeler
Markus Joschko  wrote
> Of course. But normally its well defined what you expect the user to enter.
> Be it a blog comment (title, text, mail) or an order or whatever.
> The developer knows about the syntax and semantics of these properties.
> Not so for properties that are added by the user when circumventing the UI.
> How should they be validated? Are they maybe accidentally rendered by
> a defaultservlet?
> Can the content be used for XSS then? etc.
> The security guys that I had to work with are keen on controlling the
> data. You don't need the data? Then why would you store it?

I can completly understand the security concern - you don't want people
to add or change arbitrary properties somewhere in your repository. So
it really makes sense to restrict this,

>>
>> Not necessarily, I would opt for validation inside servlet filters, custom
>> POST script/servlet or sling post processor. Node types should only be
>> used for things that you know are really fixed and won't change much in
>> the future. Such as the common nt:file and nt:folder definitions in the
>> JCR spec.
> 
> OK, then you'd keep all rules that define your model and the
> validation rules "in code" (or configured elsewhere).
> You just don't use the abilities of the JCR to check node properties.

Now, as soon as you start using node types you might hit limitations
later on as it might be hard to update your node type - same with
databases; but it's possible though.
But unfortunately I guess the node type definitions are not sufficient
when it comes to data validation - you can't specify ranges for example
etc. So you need additional validation anyway.

> That makes me want to have a controller to validate my data against my
> model and only pass the verified data to the view to render it ;-)
> Can filters be used for that task?

You could use filters or you could also use the SlingPostProcessor
concept. Handling this in a filter is more general as it would cover all
write operations not only those done through the default Sling post
servlet (you can write your own post servlets for example)

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org


Re: Evaluating sling

2011-01-05 Thread Markus Joschko
>>Mhm, correct me if I am wrong but nt:unstructured allows the user to
>>define own properties on the fly as well, or?
>>I can name at least one security consultant who would freak out if
>>people can store content "uncontrolled" in the repository.
>
> Because exactly? There would be a reason that he is allowed to add or edit
> something in the first place.

Of course. But normally its well defined what you expect the user to enter.
Be it a blog comment (title, text, mail) or an order or whatever.
The developer knows about the syntax and semantics of these properties.
Not so for properties that are added by the user when circumventing the UI.
How should they be validated? Are they maybe accidentally rendered by
a defaultservlet?
Can the content be used for XSS then? etc.
The security guys that I had to work with are keen on controlling the
data. You don't need the data? Then why would you store it?

>
>>OK, then the message is: If I want to have support for input
>>validation it makes sense to have custom node types (which might
>>inherit from nt:unstructured).
>
> Not necessarily, I would opt for validation inside servlet filters, custom
> POST script/servlet or sling post processor. Node types should only be
> used for things that you know are really fixed and won't change much in
> the future. Such as the common nt:file and nt:folder definitions in the
> JCR spec.

OK, then you'd keep all rules that define your model and the
validation rules "in code" (or configured elsewhere).
You just don't use the abilities of the JCR to check node properties.

That makes me want to have a controller to validate my data against my
model and only pass the verified data to the view to render it ;-)
Can filters be used for that task?

Regards,
 Markus