You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Jinmei Liao (JIRA)" <ji...@apache.org> on 2016/11/03 17:49:58 UTC

[jira] [Commented] (GEODE-2056) Expose GeodeSecurityService as needed

    [ https://issues.apache.org/jira/browse/GEODE-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633617#comment-15633617 ] 

Jinmei Liao commented on GEODE-2056:
------------------------------------

Some of the methods in SecurityService do make sense to be exposed, like all the authorize methods, login, getSubject, keep all the rest internal.

> Expose GeodeSecurityService as needed
> -------------------------------------
>
>                 Key: GEODE-2056
>                 URL: https://issues.apache.org/jira/browse/GEODE-2056
>             Project: Geode
>          Issue Type: Sub-task
>            Reporter: Jinmei Liao
>
> 2. I also think it is pertinent that the SecurityService interface [27] be in Geode's public API.  Given this is just an interface, I am not sure why it was decided to make it "internal" anyway?  I see no good reason NOT to expose this interface, especially since it would be particularly useful for both API/Framework (e.g. SDG) as well as tools developers developing extensions to Apache Geode.
> I actually did make use of the SecurityService interface [28] in SDG, despite my (usually) hard rule of NOT ever using any GemFire/Geode internal classes at all in SDG. Unfortunately, and all too often, in certain cases, such as the currently released version of Apache Geode, 1.0.0-incubating GA, there is simply no other way around it when providing support for securing Apache Geode, especially for making Apache Shiro first-class (something I want to similarly do for Spring Security).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)