You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by Vincenzo Turco <vi...@gmail.com> on 2013/12/13 10:54:57 UTC
How to hook up permission check into JPA-scenario?
Hi all,
I have exposed my JPA entities through the JPA processor and it works great.
Now I have added authentication to my oData service, through the
appropriate configuration in web.xml.
I would like to restrict the entries returned by the odata service
according to the logged in user.
Is there any way to hook up custom logic (e.g. in the JPA processor) to do
so?
Also any alternative solution would be greatly valued.
Thanks a lot for your time and attention
Regards
Vincenzo
--
Vincenzo Turco
Re: How to hook up permission check into JPA-scenario?
Posted by "Klevenz, Stephan" <st...@sap.com>.
Maybe you can open a feature request in JIRA and just add this discussion.
Stephan
On 14.01.14 16:26, "Vincenzo Turco" <vi...@gmail.com> wrote:
>Hi all,
>I have been following the stream update on the Olingo new features and I
>can say that there has been a lot going on.
>However I'm not sure I haven't missed something, since I have seen
>references to Interceptors often in the past updates.
>Could anyone please point out whether there's any update on the topic of
>handling security in JPA?
>Thanks a lot
>Regards
>Vincenzo
>
>
>2013/12/16 Vincenzo Turco <vi...@gmail.com>
>
>> Hi all,
>> thanks for your kind help.
>> Since the ODataJPAResponseBuilder is not part of the api, I understand
>> that the strategy of extending ODataJPAProcessor is not feasible.
>> This is because re-implementing ODataJPAResponseBuilder looks like a big
>> effort, but please feel free to correct me if I'm wrong.
>>
>> Imho, as an api-user, the scenario where access control is enforced
>> through Entity Listeners is of the greatest interest.
>> It would be great if a general idea of the timeframe for releasing this
>> feature could be made available, as I severely need it for my current
>> project.
>>
>> Thanks, regards
>> Vincenzo
>>
>>
>>
>>
>> 2013/12/16 V.A, Chandan <ch...@sap.com>
>>
>> Hello All
>>> Then I will outline a proposal in the Olingo wiki explaining how we
>>>could
>>> pass the OData JPA context (in a fail safe mode) to the JPA entity
>>> listeners.
>>>
>>> Thanks,
>>> Kind Regards
>>> Chandan VA
>>>
>>>
>>> -----Original Message-----
>>> From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>>> Sent: Friday, December 13, 2013 8:56 PM
>>> To: dev@olingo.incubator.apache.org
>>> Subject: Re: How to hook up permission check into JPA-scenario?
>>>
>>> Hi Chandan,
>>>
>>> I like your proposal, too. +1
>>>
>>> Can we ensure that a ThreadLocal is always valid also in case of a
>>>thread
>>> pooled environment?
>>>
>>>
>>>
>>>http://stackoverflow.com/questions/7403809/java-cached-thread-pool-and-t
>>>hre
>>>
>>>ad-local<http://stackoverflow.com/questions/7403809/java-cached-thread-p
>>>ool-and-thread-local>
>>>
>>> It could also cause issues in case of hot deployment:
>>>
>>>
>>>
>>>https://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thr
>>>ead
>>>
>>>-pool-bad-idea-or-dealing-apparent-glassfish-memor<https://weblogs.java.
>>>net/blog/jjviana/archive/2010/06/10/threadlocal-thread-pool-bad-idea-or-
>>>dealing-apparent-glassfish-memor>
>>>
>>> Just for information.
>>>
>>> Greetings,
>>> Stephan
>>>
>>>
>>>
>>> On 13.12.13 16:06, "V.A, Chandan" <ch...@sap.com> wrote:
>>>
>>> >Hi Vincenzo,
>>> >As Stephan mentioned you could inherit from class ODataJPAProcessor
>>>and
>>> >implement the behavior defined in ODataJPAProcessorDefault.
>>> >
>>> >You can use the API - JPAProcessor for processing an OData Request.
>>> >JPAProcessor is already available to you as a protected member
>>>variable
>>> >from ODataJPAProcessor.
>>> >However you cannot use (as of now) the ODataJPAResponseBuilder as it
>>>is
>>> >not part of API and will not be accessible when the project is
>>>executed
>>> >in an OSGi container.
>>> >
>>> >@All
>>> >Secondly just thinking out loud.
>>> >Can we push the logic of handling security to JPA Entity Listeners.
>>>Where
>>> >one could define Entity Listeners with different life cycle call back
>>> >methods to handle security. Here the only thing that is required is
>>>the
>>> >Current Principal from HTTP Request. This can be passed using a Thread
>>> >Local variable. If this sounds a better solution then we can think of
>>> >introducing context variables holding context information in a thread
>>> >local variable which can then be used by call back methods.
>>> >
>>> >WDYT?
>>> >
>>> >
>>> >
>>> >Thanks,
>>> >Kind Regards
>>> >Chandan VA
>>> >
>>> >-----Original Message-----
>>> >From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>>> >Sent: Friday, December 13, 2013 5:41 PM
>>> >To: dev@olingo.incubator.apache.org
>>> >Subject: Re: How to hook up permission check into JPA-scenario?
>>> >
>>> >Vincenzo,
>>> >
>>> >The current snapshot version gives access to request object via the
>>> >ODataContext class:
>>> >
>>> >https://issues.apache.org/jira/browse/OLINGO-26
>>> >
>>> >To hook into JPA processor implementation my idea would be to derive
>>>from
>>> >ODataJPAProcessor (api) and re-implement the behavior of
>>> >ODataJPAProcessorDefault (core) and add here your security checks.
>>>Maybe
>>> >Chandan can hook in here.
>>> >
>>> >I have never tried this scenario and you have to try out. If it leads
>>>to
>>> >success then good :) if not then continue this discussion.
>>> >
>>> >Regards,
>>> >Stephan
>>> >
>>> >
>>> >On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
>>> >
>>> >>Hi all,
>>> >>I have exposed my JPA entities through the JPA processor and it works
>>> >>great.
>>> >>Now I have added authentication to my oData service, through the
>>> >>appropriate configuration in web.xml.
>>> >>I would like to restrict the entries returned by the odata service
>>> >>according to the logged in user.
>>> >>Is there any way to hook up custom logic (e.g. in the JPA processor)
>>>to
>>> >>do
>>> >>so?
>>> >>Also any alternative solution would be greatly valued.
>>> >>Thanks a lot for your time and attention
>>> >>Regards
>>> >>Vincenzo
>>> >>
>>> >>
>>> >>--
>>> >>
>>> >>
>>> >>Vincenzo Turco
>>> >
>>>
>>>
>>
>>
>> --
>>
>>
>> Vincenzo Turco
>>
>
>
>
>--
>
>
>Vincenzo Turco
Re: How to hook up permission check into JPA-scenario?
Posted by Vincenzo Turco <vi...@gmail.com>.
Hi all,
I have been following the stream update on the Olingo new features and I
can say that there has been a lot going on.
However I'm not sure I haven't missed something, since I have seen
references to Interceptors often in the past updates.
Could anyone please point out whether there's any update on the topic of
handling security in JPA?
Thanks a lot
Regards
Vincenzo
2013/12/16 Vincenzo Turco <vi...@gmail.com>
> Hi all,
> thanks for your kind help.
> Since the ODataJPAResponseBuilder is not part of the api, I understand
> that the strategy of extending ODataJPAProcessor is not feasible.
> This is because re-implementing ODataJPAResponseBuilder looks like a big
> effort, but please feel free to correct me if I'm wrong.
>
> Imho, as an api-user, the scenario where access control is enforced
> through Entity Listeners is of the greatest interest.
> It would be great if a general idea of the timeframe for releasing this
> feature could be made available, as I severely need it for my current
> project.
>
> Thanks, regards
> Vincenzo
>
>
>
>
> 2013/12/16 V.A, Chandan <ch...@sap.com>
>
> Hello All
>> Then I will outline a proposal in the Olingo wiki explaining how we could
>> pass the OData JPA context (in a fail safe mode) to the JPA entity
>> listeners.
>>
>> Thanks,
>> Kind Regards
>> Chandan VA
>>
>>
>> -----Original Message-----
>> From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>> Sent: Friday, December 13, 2013 8:56 PM
>> To: dev@olingo.incubator.apache.org
>> Subject: Re: How to hook up permission check into JPA-scenario?
>>
>> Hi Chandan,
>>
>> I like your proposal, too. +1
>>
>> Can we ensure that a ThreadLocal is always valid also in case of a thread
>> pooled environment?
>>
>>
>> http://stackoverflow.com/questions/7403809/java-cached-thread-pool-and-thre
>> ad-local<http://stackoverflow.com/questions/7403809/java-cached-thread-pool-and-thread-local>
>>
>> It could also cause issues in case of hot deployment:
>>
>>
>> https://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread
>> -pool-bad-idea-or-dealing-apparent-glassfish-memor<https://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread-pool-bad-idea-or-dealing-apparent-glassfish-memor>
>>
>> Just for information.
>>
>> Greetings,
>> Stephan
>>
>>
>>
>> On 13.12.13 16:06, "V.A, Chandan" <ch...@sap.com> wrote:
>>
>> >Hi Vincenzo,
>> >As Stephan mentioned you could inherit from class ODataJPAProcessor and
>> >implement the behavior defined in ODataJPAProcessorDefault.
>> >
>> >You can use the API - JPAProcessor for processing an OData Request.
>> >JPAProcessor is already available to you as a protected member variable
>> >from ODataJPAProcessor.
>> >However you cannot use (as of now) the ODataJPAResponseBuilder as it is
>> >not part of API and will not be accessible when the project is executed
>> >in an OSGi container.
>> >
>> >@All
>> >Secondly just thinking out loud.
>> >Can we push the logic of handling security to JPA Entity Listeners. Where
>> >one could define Entity Listeners with different life cycle call back
>> >methods to handle security. Here the only thing that is required is the
>> >Current Principal from HTTP Request. This can be passed using a Thread
>> >Local variable. If this sounds a better solution then we can think of
>> >introducing context variables holding context information in a thread
>> >local variable which can then be used by call back methods.
>> >
>> >WDYT?
>> >
>> >
>> >
>> >Thanks,
>> >Kind Regards
>> >Chandan VA
>> >
>> >-----Original Message-----
>> >From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>> >Sent: Friday, December 13, 2013 5:41 PM
>> >To: dev@olingo.incubator.apache.org
>> >Subject: Re: How to hook up permission check into JPA-scenario?
>> >
>> >Vincenzo,
>> >
>> >The current snapshot version gives access to request object via the
>> >ODataContext class:
>> >
>> >https://issues.apache.org/jira/browse/OLINGO-26
>> >
>> >To hook into JPA processor implementation my idea would be to derive from
>> >ODataJPAProcessor (api) and re-implement the behavior of
>> >ODataJPAProcessorDefault (core) and add here your security checks. Maybe
>> >Chandan can hook in here.
>> >
>> >I have never tried this scenario and you have to try out. If it leads to
>> >success then good :) if not then continue this discussion.
>> >
>> >Regards,
>> >Stephan
>> >
>> >
>> >On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
>> >
>> >>Hi all,
>> >>I have exposed my JPA entities through the JPA processor and it works
>> >>great.
>> >>Now I have added authentication to my oData service, through the
>> >>appropriate configuration in web.xml.
>> >>I would like to restrict the entries returned by the odata service
>> >>according to the logged in user.
>> >>Is there any way to hook up custom logic (e.g. in the JPA processor) to
>> >>do
>> >>so?
>> >>Also any alternative solution would be greatly valued.
>> >>Thanks a lot for your time and attention
>> >>Regards
>> >>Vincenzo
>> >>
>> >>
>> >>--
>> >>
>> >>
>> >>Vincenzo Turco
>> >
>>
>>
>
>
> --
>
>
> Vincenzo Turco
>
--
Vincenzo Turco
Re: How to hook up permission check into JPA-scenario?
Posted by Vincenzo Turco <vi...@gmail.com>.
Hi all,
thanks for your kind help.
Since the ODataJPAResponseBuilder is not part of the api, I understand that
the strategy of extending ODataJPAProcessor is not feasible.
This is because re-implementing ODataJPAResponseBuilder looks like a big
effort, but please feel free to correct me if I'm wrong.
Imho, as an api-user, the scenario where access control is enforced through
Entity Listeners is of the greatest interest.
It would be great if a general idea of the timeframe for releasing this
feature could be made available, as I severely need it for my current
project.
Thanks, regards
Vincenzo
2013/12/16 V.A, Chandan <ch...@sap.com>
> Hello All
> Then I will outline a proposal in the Olingo wiki explaining how we could
> pass the OData JPA context (in a fail safe mode) to the JPA entity
> listeners.
>
> Thanks,
> Kind Regards
> Chandan VA
>
>
> -----Original Message-----
> From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
> Sent: Friday, December 13, 2013 8:56 PM
> To: dev@olingo.incubator.apache.org
> Subject: Re: How to hook up permission check into JPA-scenario?
>
> Hi Chandan,
>
> I like your proposal, too. +1
>
> Can we ensure that a ThreadLocal is always valid also in case of a thread
> pooled environment?
>
> http://stackoverflow.com/questions/7403809/java-cached-thread-pool-and-thre
> ad-local
>
> It could also cause issues in case of hot deployment:
>
> https://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread
> -pool-bad-idea-or-dealing-apparent-glassfish-memor
>
> Just for information.
>
> Greetings,
> Stephan
>
>
>
> On 13.12.13 16:06, "V.A, Chandan" <ch...@sap.com> wrote:
>
> >Hi Vincenzo,
> >As Stephan mentioned you could inherit from class ODataJPAProcessor and
> >implement the behavior defined in ODataJPAProcessorDefault.
> >
> >You can use the API - JPAProcessor for processing an OData Request.
> >JPAProcessor is already available to you as a protected member variable
> >from ODataJPAProcessor.
> >However you cannot use (as of now) the ODataJPAResponseBuilder as it is
> >not part of API and will not be accessible when the project is executed
> >in an OSGi container.
> >
> >@All
> >Secondly just thinking out loud.
> >Can we push the logic of handling security to JPA Entity Listeners. Where
> >one could define Entity Listeners with different life cycle call back
> >methods to handle security. Here the only thing that is required is the
> >Current Principal from HTTP Request. This can be passed using a Thread
> >Local variable. If this sounds a better solution then we can think of
> >introducing context variables holding context information in a thread
> >local variable which can then be used by call back methods.
> >
> >WDYT?
> >
> >
> >
> >Thanks,
> >Kind Regards
> >Chandan VA
> >
> >-----Original Message-----
> >From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
> >Sent: Friday, December 13, 2013 5:41 PM
> >To: dev@olingo.incubator.apache.org
> >Subject: Re: How to hook up permission check into JPA-scenario?
> >
> >Vincenzo,
> >
> >The current snapshot version gives access to request object via the
> >ODataContext class:
> >
> >https://issues.apache.org/jira/browse/OLINGO-26
> >
> >To hook into JPA processor implementation my idea would be to derive from
> >ODataJPAProcessor (api) and re-implement the behavior of
> >ODataJPAProcessorDefault (core) and add here your security checks. Maybe
> >Chandan can hook in here.
> >
> >I have never tried this scenario and you have to try out. If it leads to
> >success then good :) if not then continue this discussion.
> >
> >Regards,
> >Stephan
> >
> >
> >On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
> >
> >>Hi all,
> >>I have exposed my JPA entities through the JPA processor and it works
> >>great.
> >>Now I have added authentication to my oData service, through the
> >>appropriate configuration in web.xml.
> >>I would like to restrict the entries returned by the odata service
> >>according to the logged in user.
> >>Is there any way to hook up custom logic (e.g. in the JPA processor) to
> >>do
> >>so?
> >>Also any alternative solution would be greatly valued.
> >>Thanks a lot for your time and attention
> >>Regards
> >>Vincenzo
> >>
> >>
> >>--
> >>
> >>
> >>Vincenzo Turco
> >
>
>
--
Vincenzo Turco
RE: How to hook up permission check into JPA-scenario?
Posted by "V.A, Chandan" <ch...@sap.com>.
Hello All
Then I will outline a proposal in the Olingo wiki explaining how we could pass the OData JPA context (in a fail safe mode) to the JPA entity listeners.
Thanks,
Kind Regards
Chandan VA
-----Original Message-----
From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
Sent: Friday, December 13, 2013 8:56 PM
To: dev@olingo.incubator.apache.org
Subject: Re: How to hook up permission check into JPA-scenario?
Hi Chandan,
I like your proposal, too. +1
Can we ensure that a ThreadLocal is always valid also in case of a thread
pooled environment?
http://stackoverflow.com/questions/7403809/java-cached-thread-pool-and-thre
ad-local
It could also cause issues in case of hot deployment:
https://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread
-pool-bad-idea-or-dealing-apparent-glassfish-memor
Just for information.
Greetings,
Stephan
On 13.12.13 16:06, "V.A, Chandan" <ch...@sap.com> wrote:
>Hi Vincenzo,
>As Stephan mentioned you could inherit from class ODataJPAProcessor and
>implement the behavior defined in ODataJPAProcessorDefault.
>
>You can use the API - JPAProcessor for processing an OData Request.
>JPAProcessor is already available to you as a protected member variable
>from ODataJPAProcessor.
>However you cannot use (as of now) the ODataJPAResponseBuilder as it is
>not part of API and will not be accessible when the project is executed
>in an OSGi container.
>
>@All
>Secondly just thinking out loud.
>Can we push the logic of handling security to JPA Entity Listeners. Where
>one could define Entity Listeners with different life cycle call back
>methods to handle security. Here the only thing that is required is the
>Current Principal from HTTP Request. This can be passed using a Thread
>Local variable. If this sounds a better solution then we can think of
>introducing context variables holding context information in a thread
>local variable which can then be used by call back methods.
>
>WDYT?
>
>
>
>Thanks,
>Kind Regards
>Chandan VA
>
>-----Original Message-----
>From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>Sent: Friday, December 13, 2013 5:41 PM
>To: dev@olingo.incubator.apache.org
>Subject: Re: How to hook up permission check into JPA-scenario?
>
>Vincenzo,
>
>The current snapshot version gives access to request object via the
>ODataContext class:
>
>https://issues.apache.org/jira/browse/OLINGO-26
>
>To hook into JPA processor implementation my idea would be to derive from
>ODataJPAProcessor (api) and re-implement the behavior of
>ODataJPAProcessorDefault (core) and add here your security checks. Maybe
>Chandan can hook in here.
>
>I have never tried this scenario and you have to try out. If it leads to
>success then good :) if not then continue this discussion.
>
>Regards,
>Stephan
>
>
>On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
>
>>Hi all,
>>I have exposed my JPA entities through the JPA processor and it works
>>great.
>>Now I have added authentication to my oData service, through the
>>appropriate configuration in web.xml.
>>I would like to restrict the entries returned by the odata service
>>according to the logged in user.
>>Is there any way to hook up custom logic (e.g. in the JPA processor) to
>>do
>>so?
>>Also any alternative solution would be greatly valued.
>>Thanks a lot for your time and attention
>>Regards
>>Vincenzo
>>
>>
>>--
>>
>>
>>Vincenzo Turco
>
Re: How to hook up permission check into JPA-scenario?
Posted by Carl Mosca <ca...@gmail.com>.
Chandan,
I like your idea of making it possible to handle security logic in the JPA
Entity Listeners.
Carl
On Fri, Dec 13, 2013 at 10:06 AM, V.A, Chandan <ch...@sap.com> wrote:
> Hi Vincenzo,
> As Stephan mentioned you could inherit from class ODataJPAProcessor and
> implement the behavior defined in ODataJPAProcessorDefault.
>
> You can use the API - JPAProcessor for processing an OData Request.
> JPAProcessor is already available to you as a protected member variable
> from ODataJPAProcessor.
> However you cannot use (as of now) the ODataJPAResponseBuilder as it is
> not part of API and will not be accessible when the project is executed in
> an OSGi container.
>
> @All
> Secondly just thinking out loud.
> Can we push the logic of handling security to JPA Entity Listeners. Where
> one could define Entity Listeners with different life cycle call back
> methods to handle security. Here the only thing that is required is the
> Current Principal from HTTP Request. This can be passed using a Thread
> Local variable. If this sounds a better solution then we can think of
> introducing context variables holding context information in a thread local
> variable which can then be used by call back methods.
>
> WDYT?
>
>
>
> Thanks,
> Kind Regards
> Chandan VA
>
> -----Original Message-----
> From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
> Sent: Friday, December 13, 2013 5:41 PM
> To: dev@olingo.incubator.apache.org
> Subject: Re: How to hook up permission check into JPA-scenario?
>
> Vincenzo,
>
> The current snapshot version gives access to request object via the
> ODataContext class:
>
> https://issues.apache.org/jira/browse/OLINGO-26
>
> To hook into JPA processor implementation my idea would be to derive from
> ODataJPAProcessor (api) and re-implement the behavior of
> ODataJPAProcessorDefault (core) and add here your security checks. Maybe
> Chandan can hook in here.
>
> I have never tried this scenario and you have to try out. If it leads to
> success then good :) if not then continue this discussion.
>
> Regards,
> Stephan
>
>
> On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
>
> >Hi all,
> >I have exposed my JPA entities through the JPA processor and it works
> >great.
> >Now I have added authentication to my oData service, through the
> >appropriate configuration in web.xml.
> >I would like to restrict the entries returned by the odata service
> >according to the logged in user.
> >Is there any way to hook up custom logic (e.g. in the JPA processor) to do
> >so?
> >Also any alternative solution would be greatly valued.
> >Thanks a lot for your time and attention
> >Regards
> >Vincenzo
> >
> >
> >--
> >
> >
> >Vincenzo Turco
>
>
--
Carl J. Mosca
Re: How to hook up permission check into JPA-scenario?
Posted by "Klevenz, Stephan" <st...@sap.com>.
Hi Chandan,
I like your proposal, too. +1
Can we ensure that a ThreadLocal is always valid also in case of a thread
pooled environment?
http://stackoverflow.com/questions/7403809/java-cached-thread-pool-and-thre
ad-local
It could also cause issues in case of hot deployment:
https://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread
-pool-bad-idea-or-dealing-apparent-glassfish-memor
Just for information.
Greetings,
Stephan
On 13.12.13 16:06, "V.A, Chandan" <ch...@sap.com> wrote:
>Hi Vincenzo,
>As Stephan mentioned you could inherit from class ODataJPAProcessor and
>implement the behavior defined in ODataJPAProcessorDefault.
>
>You can use the API - JPAProcessor for processing an OData Request.
>JPAProcessor is already available to you as a protected member variable
>from ODataJPAProcessor.
>However you cannot use (as of now) the ODataJPAResponseBuilder as it is
>not part of API and will not be accessible when the project is executed
>in an OSGi container.
>
>@All
>Secondly just thinking out loud.
>Can we push the logic of handling security to JPA Entity Listeners. Where
>one could define Entity Listeners with different life cycle call back
>methods to handle security. Here the only thing that is required is the
>Current Principal from HTTP Request. This can be passed using a Thread
>Local variable. If this sounds a better solution then we can think of
>introducing context variables holding context information in a thread
>local variable which can then be used by call back methods.
>
>WDYT?
>
>
>
>Thanks,
>Kind Regards
>Chandan VA
>
>-----Original Message-----
>From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>Sent: Friday, December 13, 2013 5:41 PM
>To: dev@olingo.incubator.apache.org
>Subject: Re: How to hook up permission check into JPA-scenario?
>
>Vincenzo,
>
>The current snapshot version gives access to request object via the
>ODataContext class:
>
>https://issues.apache.org/jira/browse/OLINGO-26
>
>To hook into JPA processor implementation my idea would be to derive from
>ODataJPAProcessor (api) and re-implement the behavior of
>ODataJPAProcessorDefault (core) and add here your security checks. Maybe
>Chandan can hook in here.
>
>I have never tried this scenario and you have to try out. If it leads to
>success then good :) if not then continue this discussion.
>
>Regards,
>Stephan
>
>
>On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
>
>>Hi all,
>>I have exposed my JPA entities through the JPA processor and it works
>>great.
>>Now I have added authentication to my oData service, through the
>>appropriate configuration in web.xml.
>>I would like to restrict the entries returned by the odata service
>>according to the logged in user.
>>Is there any way to hook up custom logic (e.g. in the JPA processor) to
>>do
>>so?
>>Also any alternative solution would be greatly valued.
>>Thanks a lot for your time and attention
>>Regards
>>Vincenzo
>>
>>
>>--
>>
>>
>>Vincenzo Turco
>
RE: How to hook up permission check into JPA-scenario?
Posted by "V.A, Chandan" <ch...@sap.com>.
Hi Vincenzo,
As Stephan mentioned you could inherit from class ODataJPAProcessor and implement the behavior defined in ODataJPAProcessorDefault.
You can use the API - JPAProcessor for processing an OData Request. JPAProcessor is already available to you as a protected member variable from ODataJPAProcessor.
However you cannot use (as of now) the ODataJPAResponseBuilder as it is not part of API and will not be accessible when the project is executed in an OSGi container.
@All
Secondly just thinking out loud.
Can we push the logic of handling security to JPA Entity Listeners. Where one could define Entity Listeners with different life cycle call back methods to handle security. Here the only thing that is required is the Current Principal from HTTP Request. This can be passed using a Thread Local variable. If this sounds a better solution then we can think of introducing context variables holding context information in a thread local variable which can then be used by call back methods.
WDYT?
Thanks,
Kind Regards
Chandan VA
-----Original Message-----
From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
Sent: Friday, December 13, 2013 5:41 PM
To: dev@olingo.incubator.apache.org
Subject: Re: How to hook up permission check into JPA-scenario?
Vincenzo,
The current snapshot version gives access to request object via the
ODataContext class:
https://issues.apache.org/jira/browse/OLINGO-26
To hook into JPA processor implementation my idea would be to derive from
ODataJPAProcessor (api) and re-implement the behavior of
ODataJPAProcessorDefault (core) and add here your security checks. Maybe
Chandan can hook in here.
I have never tried this scenario and you have to try out. If it leads to
success then good :) if not then continue this discussion.
Regards,
Stephan
On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
>Hi all,
>I have exposed my JPA entities through the JPA processor and it works
>great.
>Now I have added authentication to my oData service, through the
>appropriate configuration in web.xml.
>I would like to restrict the entries returned by the odata service
>according to the logged in user.
>Is there any way to hook up custom logic (e.g. in the JPA processor) to do
>so?
>Also any alternative solution would be greatly valued.
>Thanks a lot for your time and attention
>Regards
>Vincenzo
>
>
>--
>
>
>Vincenzo Turco
Re: How to hook up permission check into JPA-scenario?
Posted by "Klevenz, Stephan" <st...@sap.com>.
Vincenzo,
The current snapshot version gives access to request object via the
ODataContext class:
https://issues.apache.org/jira/browse/OLINGO-26
To hook into JPA processor implementation my idea would be to derive from
ODataJPAProcessor (api) and re-implement the behavior of
ODataJPAProcessorDefault (core) and add here your security checks. Maybe
Chandan can hook in here.
I have never tried this scenario and you have to try out. If it leads to
success then good :) if not then continue this discussion.
Regards,
Stephan
On 13.12.13 10:54, "Vincenzo Turco" <vi...@gmail.com> wrote:
>Hi all,
>I have exposed my JPA entities through the JPA processor and it works
>great.
>Now I have added authentication to my oData service, through the
>appropriate configuration in web.xml.
>I would like to restrict the entries returned by the odata service
>according to the logged in user.
>Is there any way to hook up custom logic (e.g. in the JPA processor) to do
>so?
>Also any alternative solution would be greatly valued.
>Thanks a lot for your time and attention
>Regards
>Vincenzo
>
>
>--
>
>
>Vincenzo Turco