[Engine-devel] restapi - domains

Mon Mar 18 12:24:23 UTC 2013

Hi,

> Yeah, but you have to type domain name precisely instead of just choosing familiar one...

Yes.. Just like having to type user name precisely :) it depends on what users feel more comfortable with..

Vojtech

----- Original Message -----
From: "David Jaša" <djasa at redhat.com>
To: engine-devel at ovirt.org
Sent: Saturday, March 16, 2013 8:47:17 PM
Subject: Re: [Engine-devel] restapi - domains

Vojtech Szocs píše v Pá 15. 03. 2013 v 14:09 -0400:
> Hi,
> 
> in WebAdmin/UserPortal GUI, it's possible to enter 'username at domain' into User Name input field. After doing this, Domain drop-down becomes disabled. This is actually how auto-login works from GUI perspective.
> 
> So GetDomainList public query + Domain drop-down aren't really necessary for performing user login in GUI..

Yeah, but you have to type domain name precisely instead of just choosing familiar one...

David

> 
> Vojtech
> 
> 
> ----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: "Shireesh Anjal" <sanjal at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, March 11, 2013 10:43:25 AM
> Subject: Re: [Engine-devel] restapi - domains
> 
> On 03/11/2013 10:37 AM, Michael Pasternak wrote:
> > On 03/11/2013 10:19 AM, Shireesh Anjal wrote:
> >> On 03/09/2013 12:52 AM, Itamar Heim wrote:
> >>> On 03/08/2013 06:04 AM, Shireesh Anjal wrote:
> >>>> On 03/07/2013 01:05 PM, Aravinda wrote:
> >>>>> We can have only two fields in login screen, username and password.
> >>>>> Username will include domain name(username at domain).
> >>>>>
> >>>>> Default domain name can be "internal" if user didn't enter the domain
> >>>>> name as part of username then we can append the default value and
> >>>>> validate.
> >>>>>
> >>>>> Note: We use username at domain as username when we connect through
> >>>>> <rest_api_url>/api
> >>>>
> >>>> The idea is to *not* have the user type in the domain name, but rather
> >>>> let him/her choose one, just like what happens in webadmin. We should
> >>>> try and minimize typing as much as possible when it comes to mobile apps.
> >>>
> >>> I think this was done on purpose for some reason to not provide a public api for the rest api, but i could be wrong and don't remember the detail.
> >>> as the concepts of multi tenancy and multiple domains grow, providing the list of domains is considered an issue,
> >>
> >> Is it an issue specific to restapi? For we *do show* the list of domains in webadmin login screen.
> 
> yes, but we may want to remove that going forward and not show the 
> domains, as most sites don't, which allows using more domains, without 
> exposing them to other users.
> 
> >
> > indeed, UI using public query for that, while in api each request has to be authenticated,
> > as workaround, i suggest creating internal user for this purpose and using it in the app
> > (internally) to fetch entities that should not require explicit authentication from the
> > application PoV.
> 
> i assume rest api can use the public queries as well if we go that way?
> 
> >
> >>
> >>> and most systems today require user to provide their full user/domain (well, usually in the form of their email address).
> >>>
> >>>>
> >>>>>
> >>>>> --
> >>>>> regards
> >>>>> Aravinda
> >>>>>
> >>>>> On 03/07/2013 11:15 AM, Shireesh Anjal wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> We are trying to develop a simple android app to monitor and manage
> >>>>>> gluster clusters by consuming the restapi exposed by engine. The
> >>>>>> first screen is the login screen, which is similar to the webadmin
> >>>>>> login screen. Here, we want to populate the combo box of "domains" by
> >>>>>> fetching it from the restapi. However, the domains api cannot be
> >>>>>> invoked without authentication! So we have a sort of a
> >>>>>> chicken-and-egg problem.
> >>>>>>
> >>>>>> Any suggestions on how to tackle this? I feel the "domains" api
> >>>>>> should be "public", in the sense it should not expect authentication.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Shireesh
> >>>>>> _______________________________________________
> >>>>>> Engine-devel mailing list
> >>>>>> Engine-devel at ovirt.org
> >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel