<div dir="ltr">That would work: -n, --no-format<div><br></div><div>Much better than -n, --no-pretty :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 12:12 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-07-22, Marko Strukelj wrote:<br>
</span><span class="">> On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>><br>
> wrote:<br>
><br>
> > A few questions from me:<br>
> ><br>
> > * Is it possible to view the returned JSON when creating and updating a<br>
> > client? This contains values filled in by the server, including the<br>
> > registration access token.<br>
> ><br>
> Not ATM. I can add an option e.g. -o, --output Display the new state<br>
> of client configuration.<br>
><br>
><br>
> > * Should we not enable pretty print by default?<br>
> ><br>
> I suppose that would be more user friendly. Just don't know how to name the<br>
> switch -p, --pretty is so obvious ...<br>
<br>
</span>Some command line interfaces use --format.<br>
<div><div class="h5"><br>
><br>
><br>
> > * --cache isn't the most intuitive name, I don't have a better suggestion<br>
> > though<br>
> ><br>
> OpenShift client uses the term configuration rather than cache, and uses<br>
> --config accordingly. We could do the same, and even add 'kcreg config'<br>
> command to inspect and edit the config file if we deem that necessary.<br>
><br>
> * Docs should be moved to Gitbook "Securing Clients and Applications guide"<br>
> ><br>
> The only doc currently is the README file, so I guess that's the one you<br>
> mean. I'd wait a bit with adding it to docbook. The later I make a copy in<br>
> Gitbook the less double work will there be editing the changes.<br>
><br>
><br>
> > * When creating clients and later updating them I assume it uses the<br>
> > registration access token from the cache?<br>
> ><br>
> Yes. If it can't find one it uses bearer token from login.<br>
><br>
><br>
> > * A nice addition would be the ability to list attributes from<br>
> > ClientRepresentation so it's easy to discover what attributes can be set<br>
> ><br>
> That's trivial to add using reflection. But how would the UI look? Ideally<br>
> we'd have tab completion for this at some point.<br>
><br>
> Something like this?<br>
><br>
> $ kcreg list-attrs<br>
> clientId String<br>
> redirectUris List<String><br>
> baseUrl String<br>
> enabled Boolean<br>
> ...<br>
><br>
> $ kcreg list-attrs -e oidc<br>
> redirect_uris List<String><br>
> grant_types List<String><br>
><br>
><br>
> However if we want to be more specific, with some additional help on the<br>
> meaning, and possible values, then we would need to annotate Representation<br>
> classes with the necessary info, or simply have a help-style static text.<br>
><br>
><br>
><br>
> > * What about setting/changing complex attributes, how does that look like?<br>
> > Can we add/remove to an array? Add/remove elements to a complex object?<br>
> > Something like JSON patch could be nice<br>
> > <a href="https://tools.ietf.org/html/rfc6902" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc6902</a><br>
> ><br>
> I haven't gone so far with this iteration. That's a TODO.<br>
><br>
><br>
> ><br>
> > On 22 July 2016 at 09:26, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>> wrote:<br>
> ><br>
> >> It should be fairly easy to add support for OTP as well as the direct<br>
> >> grant supports that. The user would have to specify to use OTP though.<br>
> >><br>
> >> On 21 July 2016 at 19:15, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
> >><br>
> >>> Nice work Marko! I had two (not big deal) questions. First, when you<br>
> >>> specify the --cache parameters as you did for SAML, could the cache file<br>
> >>> be omitted?<br>
> >>><br>
> >>> For example: kcreg --cache -r saml-realm ...<br>
> >>><br>
> >>> I was thinking that once you specified the realm name, the API will just<br>
> >>> look for ~/.keycloak/saml-realm.cache. It's just an idea.<br>
> >>><br>
> >>> Second question, is more like something to think if worth to take<br>
> >>> into consideration. Most of the examples that I saw, make use of<br>
> >>> username/password. But if the admin enables two factor authentication,<br>
> >>> she might be unable to use our client-reg CLI, or enforce weaken<br>
> >>> security only<br>
> >>> to make use of the CLI.<br>
> >>><br>
> >>> Is OTP support planned for further iterations?<br>
> >>><br>
> >>><br>
> >>> On 2016-07-21, Marko Strukelj wrote:<br>
> >>> > And if anyone wants to get their feet wet already:<br>
> >>> ><br>
> >>> ><br>
> >>> <a href="https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool" rel="noreferrer" target="_blank">https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool</a><br>
> >>> ><br>
> >>> ><br>
> >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a><br>
> >>> ><br>
> >>> > wrote:<br>
> >>> ><br>
> >>> > > Great work Marko!<br>
> >>> > ><br>
> >>> > > As we didn't have time to go through feedback let's use this thread<br>
> >>> for<br>
> >>> > > it. Add your questions and comments here please.<br>
> >>> > ><br>
> >>> > > _______________________________________________<br>
> >>> > > keycloak-dev mailing list<br>
> >>> > > <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> >>> > > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
> >>> > ><br>
> >>><br>
> >>> > _______________________________________________<br>
> >>> > keycloak-dev mailing list<br>
> >>> > <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> >>> > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>><br>
> >>> abstractj<br>
> >>> PGP: 0x84DC9914<br>
> >>><br>
> >><br>
> >><br>
> ><br>
<br>
</div></div>--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
</blockquote></div><br></div>