[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Is there any administration API to manage the app/cartridges as system admin



See the following in broker.conf:


# Set the default and maximum expiration for authorization tokens by
# type.  Comma delimited list of expiration pairs, where the key 
# corresponds the canonical form of a scope, and the value corresponds 
# to one or two time durations.  The time durations may be specified in 
# standard ruby syntax (<number>.days) are converted to seconds.  If two
# times are specified, the first is the default value and the second is
# the maximum duration the token may exist for. The key '*' will apply
# to all other scopes.
# 
# Recognized scopes:
#
#   userinfo - access to only information about the current user
#   read     - read-only access to the REST API
#   session  - full access as the user
# 
# Examples:
#
#   # All tokens, regardless of type, expire in 1 month and default to
#   # 1 month in duration.
#   AUTH_SCOPE_TIMEOUTS="*=1.months"   
#
#   # All tokens, regardless of type, expire in 1 month and default to
#   # 1 week in duration.
#   AUTH_SCOPE_TIMEOUTS="*=1.week|1.months"   
#
#   # The read scope expires in 1 day, all other tokens expire in one
#   # week.
#   AUTH_SCOPE_TIMEOUTS="read=1.month, *=1.week"
#
# The value may be any valid Ruby expression that evaluates to a number.
#
AUTH_SCOPE_TIMEOUTS="session=1.days|7.days, *=1.months|6.months"


If you want session scope to last for a year, do:

  AUTH_SCOPE_TIMEOUTS="session=1.year, *=1.months|6.months"

or 2 years

  AUTH_SCOPE_TIMEOUTS="session=2.years, *=1.months|6.months"

or all tokens last 2 years

  AUTH_SCOPE_TIMEOUTS="*=2.years"

----- Original Message -----
> another question is, how can I tune the expiration? to
> configure expires_in? can I configure it as infinite (won't expire)?
> 
> thanks
> 
>   Thanks & Best Regards!
> 
>                   ///
>                  (. .)
>   --------ooO--(_)--Ooo--------
>   |           Nick Tan           |
>   ------------------------------------
> 
> 
> On Fri, Jun 21, 2013 at 9:03 AM, XuQing Tan <missedone gmail com> wrote:
> 
> > thanks for your reply
> >
> > before read the code to understand the logic of remote-user auth, here i
> > have one question:
> > if i hack to use the auth proxy, aka, remote-user, will the basic auth
> > still applied? i mean if i hack to put my admin token in the remote-user,
> > if the user's basic auth not applied, how can i know it's a valid user?
> >
> >
> >   Thanks & Best Regards!
> >
> >                   ///
> >                  (. .)
> >   --------ooO--(_)--Ooo--------
> >   |           Nick Tan           |
> >   ------------------------------------
> >
> >
> > On Wed, Jun 19, 2013 at 9:32 PM, Clayton Coleman
> > <ccoleman redhat com>wrote:
> >
> >> That's tunable to admins - can set an arbitrary expiration in OSE or
> >> origin
> >>
> >> On Jun 19, 2013, at 8:35 AM, Andy Goldstein <agoldste redhat com> wrote:
> >>
> >> >
> >> > On Jun 19, 2013, at 4:36 AM, Brenton Leanhardt wrote:
> >> >
> >> >> +++ XuQing Tan [19/06/13 16:26 +0800]:
> >> >>> hi, Krishna
> >> >>>
> >> >>> i'm working on a PoC to integrate openshift origin with our existing
> >> system
> >> >>> (it's kind of a ticket system, that user can request to create app
> >> etc).
> >> >>>
> >> >>> as the system admin, now i want to programmatically create the app on
> >> >>> openshift for the user.
> >> >>>
> >> >>> note that, as system admin, i don't have the user's credentials (they
> >> are
> >> >>> in LDAP, i don't have access). but for now, i found that openshift
> >> rest API
> >> >>> request the user's credentials to create the app.
> >> >>>
> >> >>> so, have can I use my system admin account, to create the app for
> >> that user?
> >> >>
> >> >> I'm betting the proper way to do this would be to somehow generate an
> >> >> authorization token that would give all you to create applications on
> >> >> behalf of another user.
> >> >
> >> > Our tokens expire after 24 hours, right? That could be a bit of a
> >> wrinkle if you go that routeā€¦ ?
> >> >
> >> >>
> >> >> A hackish way to do this is to use the remote-user authentication
> >> >> plugin.  All requests coming in to the SSL-termination proxy require
> >> >> authentication.  However if you have access to localhost:8080 on the
> >> >> Broker machine you can set the REMOTE_USER header to whatever user you
> >> >> wish.  Then you could create applications using curl or anything that
> >> >> can generate the appropriate request.
> >> >>
> >> >>>
> >> >>> thanks:)
> >> >>>
> >> >>> Thanks & Best Regards!
> >> >>>
> >> >>>                ///
> >> >>>               (. .)
> >> >>> --------ooO--(_)--Ooo--------
> >> >>> |           Nick Tan           |
> >> >>> ------------------------------------
> >> >>
> >> >>> _______________________________________________
> >> >>> dev mailing list
> >> >>> dev lists openshift redhat com
> >> >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> >>
> >> >> _______________________________________________
> >> >> dev mailing list
> >> >> dev lists openshift redhat com
> >> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> >
> >> >
> >> > _______________________________________________
> >> > dev mailing list
> >> > dev lists openshift redhat com
> >> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev lists openshift redhat com
> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >>
> >
> >
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]