Maybe you can open a feature request in JIRA and just add this discussion. Stephan
On 14.01.14 16:26, "Vincenzo Turco" <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> >> >> 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:[email protected]] >>> Sent: Friday, December 13, 2013 8:56 PM >>> To: [email protected] >>> 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" <[email protected]> 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:[email protected]] >>> >Sent: Friday, December 13, 2013 5:41 PM >>> >To: [email protected] >>> >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" <[email protected]> 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
