[keycloak-dev] Feedback on Client Registration CLI

[Marko Strukelj]

That would work: -n, --no-format

Much better than -n, --no-pretty  :)

On Fri, Jul 22, 2016 at 12:12 PM, Bruno Oliveira <bruno at abstractj.org>
wrote:

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