Mailing-List: contact clerezza-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: clerezza-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: reto@trialox.org
In-Reply-To: <AANLkTikeHk1X=mhGHNZyj7OPbSL+2CopNe82SXKvA3cK@mail.gmail.com>
References: <1289325545.1455.14.camel@Nokia-N900-51-1>
	<AANLkTikeHk1X=mhGHNZyj7OPbSL+2CopNe82SXKvA3cK@mail.gmail.com>
Date: Wed, 10 Nov 2010 11:55:35 +0100
Message-ID: <AANLkTin+1XTfB90ze8VVy+h_HDJ0tg3Ga70pRGz4GJnw@mail.gmail.com>
Subject: Re: Accessing services from scala server pages
From: Reto Bachmann-Gmuer <reto.bachmann@trialox.org>
To: Tsuyoshi Ito <tsuy.ito@trialox.org>
Cc: clerezza-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Tsuy

You're right that its probably not possible to have the permssions
based on code-base, as the invoked service has its usual code-base. So
maybe just making sure ssp are executed as anonymous independently on
a logged in user. However that way an ssp could still do things as
priviledged.

The other two variants are independent of the permission system. Th
first one would go like this:

if a Service Interface is annotated with @AvailableFromSsp (or
@SideEffectFree) then it is available with something like
$[org.example.ServiceInterface] other not.

At the cost of more complexity (dynamic proxies) I think it would also
be possible to annote single methods as @SideEffectFree, so
$[org.example.ServiceInterface].getValue() would work, but
$[org.example.ServiceInterface].clear() would throw an Exception.

Are things clearer now?

Cheers,
Reto


On Wed, Nov 10, 2010 at 10:30 AM, Tsuyoshi Ito <tsuy.ito@trialox.org> wrote=
:
> Hi Reto
>
> 2010/11/9 Reto Bachmann-Gm=C3=BCr <reto.bachmann@trialox.org>:
>> I've been skeptical toward the proposal of allowing access to osgi servi=
ces from ssp. As an alternative I suggested a special in interface (WebRend=
eringFunction) services can expose to provide a side-effect free function t=
o be used in ssp.
>>
>> It turns out that such a function needs fleixibility both for arguments =
and for return type. As an alternative I thouht of following alternatives:
>>
>> - ssp can access any service, but by running with a particular set of co=
de base permissions they cannot succesfully invoke functions that e.g. modi=
fy an mgraph.
>> - ssp can access only services which are annotated indicating to be suit=
able for that use
>> - as abobe but on method level (harder to implement)
>>
>
> I don't really understand how you would implement the first proposal.
> can you please explain it in more details (or can you give me a link
> where I can find more information about it). How would you set the
> code base permission? On class level? You wrote: "cannot succesfully
> invoke functions" - do you mean invoke/use classes? If not, what is
> the difference between proposal 1 and proposal 3? Can you please make
> an example (on an abstract level).
>
> Thanks
> Tsuy
>