[keycloak-dev] Accessing KeycloakDeployment from KeycloakSecurityContext

[Scott Rossillo]

We’re casting as well. I think the only time a KeycloakSecurityContext is not a RefreshableKeycloakSecurityContext is when you make a request from one client to another. I agree the codebase could really be improved here to avoid the constant casts. I’m thinking of sending a PR to improve this.


Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Jan 6, 2016, at 4:51 AM, Thomas Raehalme <thomas.raehalme at aitiofinland.com> wrote:
> 
> On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
> Not sure, I am like 50/50 . I agree it can simplify some scenarios when KeycloakDeployment is accessible from KeycloakSecurityContext. On the other hand, KeycloakDeployment exposes some info, which is not necessary to be exposed in client apps. 
> 
> I haven't really studied the details of KeycloakDeployment, but was under the impression that it just holds the data from keycloak.json with the addition of some client related info obtained from Keycloak. Is there anything that needs to be hidden from the client especially if the client can still obtain the object through RefreshableKeycloakSecurityContext?
> 
> What I was interested in was the accountUrl and resourceName so that I can provide a link to users to change their password. 
>  
> I think you can just cast KeycloakSecurityContext to RefreshableKeycloakSecurityContext and get KeycloakDeployment from there?
> 
> That's what I'm doing now, but I think it's more of a hack than a real solution.
> 
> Best regards,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160106/748dc208/attachment.html