Ignacio Renuncio wrote:
> > If you have images which should not be world-readable then 
> > currently the only way to use ImageServlet is to have a cloud 
> > in the session. (See e.g. how <mm:image /> works in a 
> > logged-in page). The idea is that is it no problem if 
> > authorized users use the session.
> 
> Good solution, but it's a portal with anoymous visitors so I think I can't
> take that approach because the credentials supplied have administrative
> rights (needed to be able to retrieve -any- required info). I could use a
> 'restricted user' instead, and put it on session. But that's really the
> purpose of the built-in 'anonymous', isn't it?

No, in that case you'd indeed better not use that. Of course it is a bit odd that 
anonymous visitors
see info which they actually may not. So, the most clean solution is that you make 
sure that they
indeed may view images, also according to the security system itself. I understand 
that this might
be a bit tricky, but there are a few ways you can think of (handle it in the editors, 
or in the
builder implementation or so).


> > There is no way to supply credentials directly to 
> > ImageServlet. It would perhaps be an idea to make 
> > ImageServlet try 'class security' as well, because then you 
> > can in that way easily configure that images are always 
> > viewable, regardless of security settings which could 
> > simplify setting up security somewhat.

This solution would also solve the problem, but I think ImageServlet itself needs to 
be changed a
bit for this. It can be viewed as a feature 'wish'.

It think ImageServlet is smart enough to refuse serving 'icache' nodes of which the 
real node is
lacking read-rights (because then you will still be able to see it without having 
logged in), but
I'm not even 100% sure. You could check it, otherwise you could simply make sure you 
only serve
icaches which are always of 'imagesmodule' IIRC.

Michiel

-- 
Michiel Meeuwissen                  mihxil'
Mediacentrum 140 H'sum                [] ()
+31 (0)35 6772979         nl_NL eo_XX en_US




Reply via email to