fuel-dev team mailing list archive

[Alexander Kislitsky <akislitsky@xxxxxxxxxxxx>]

I can answer on the 2-nd question:

Tracking of the logout  can be useful for logs analyse - for example if
token is used after logout - it can detect that token has been stolen.
Tracking of login/logout is not required by stat collector but this
information can be used for some analytic reports.

On Fri, Sep 26, 2014 at 1:53 AM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>
wrote:

> My 5 cents on this:
>
>    1. Why don't we drive such conversations in openstack-dev? We don't
>    have Keystone devs in this mailing list, and it seems good general question
>    which someone could help to resolve. My strong suggestion is to move to
>    openstack-dev for other similar discussions. For example, subject could
>    look like "[Fuel] [Keystone] Login and Logout actions are absent in Fuel's
>    Nailgun" - and it could attract more people into discussion.
>    2. Please someone explain to me why do we want to track logout action
>    by stats collector
>    3. Logout can be as simple as token removal from client cache (UI or
>    CLI, no matter) - in case if don't need to track logout action. I think
>    it's useful feature though - let's say, I'm using someone's browser, and
>    don't want my token live there even another minute.
>    4. Support of services discovery, multiple services authx in Keystone
>    is mandatory for Fuel's future, as pointed out Lukasz. It fully aligns with
>    my vision. Let me know if it is doable by the approach you are proposing.
>    5. Benefits of switching over from what has been implemented are not
>    clear to me. Please clarify.
>
> Thanks,
>
> On Thursday, September 25, 2014, Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx>
> wrote:
>
>> Hi Lukasz,
>>
>> > If this doesn't convince you I don't know what can :)
>>
>> Actually, I understand your points and agree with some of them, but
>> still think that we're doing that wrong way. But as I see, nobody
>> cares and the team is ok with current approach. Let's keep things as
>> they are, then.
>>
>>
>> > we also will use keystone as service/endpoint discovery tool.
>>
>> Indeed, it's a cool possible usercase.
>>
>>
>> > Do you now, that you are proposing to introduce backward
>> > incompatible change?
>>
>> No, I don't know why it's backward incompatible change. If we add
>> Nailgun auth logic which will use keystone inside - there's no
>> incompatible changes, since we will still use keystone auth token.
>>
>>
>> > Why do you need this in the first place? If you want to know when user
>> is
>> > using UI you can do it by adding special header in JavaScript client.
>> > You can easly detect when user started and stopped using UI.
>> > You can do the same with fuelclient.
>>
>> I'd prefer to refuse to count such metrics rather than use hacks in
>> headers. :)
>>
>>
>> Thanks,
>> Igor
>>
>> On Wed, Sep 24, 2014 at 10:44 PM, Lukasz Oles <loles@xxxxxxxxxxxx> wrote:
>> > Hi Igor,
>> >
>> > On Wed, Sep 24, 2014 at 8:58 AM, Igor Kalnitsky <
>> ikalnitsky@xxxxxxxxxxxx>
>> > wrote:
>> >>
>> >> In Fuel we need authentication only for Nailgun and we don't need it
>> >> for other parts of Fuel, right?
>> >
>> >
>> > Actually no. Currently nailgun and ostf are using keystone for
>> > authentication/authorization.
>> > In next release we will introduce Plugin Manager which will be separate
>> > service. It will also require
>> > keystone.
>> > So for now I know about 3 services.
>> > Some advanced plugins with their own API will also require keystone.
>> > Currently we are also working[1] on testing Fuel on large scale and we
>> may
>> > use Rally[2] for this. Rally requires keystone.
>> > It uses it to discover nailgun service.
>> > In future we may add to fuelclient  OSTF and Plugin support and we also
>> will
>> > use keystone as service/endpoint discovery tool. Anyone can use it this
>> way,
>> > as in OpenStack.
>> > Also if someone comes to us from OpenStack world  he already knows what
>> to
>> > do. After all we are building OpenStack installation tool here.
>> >
>> > If this doesn't convince you I don't know what can :)
>> >
>> >>
>> >>  For example, if we will decide
>> >> to use Keystone v3 the only thing we will have to do is to change only
>> >> Nailgun, not all clients.
>> >
>> > Actually keystone here is better than nailgun here  because it can
>> support
>> > many API versions. Do you now, that you are proposing to introduce
>> backward
>> > incompatible change?
>> >
>> > Why do you need this in the first place? If you want to know when user
>> is
>> > using UI you can do it by adding special header in JavaScript client.
>> You
>> > can easly detect when user started and stopped using UI. You can do the
>> same
>> > with fuelclient.
>> > I don't see any reason to make such change.
>> >
>> > [1] https://review.openstack.org/#/c/119400/
>> > [2] https://github.com/stackforge/rally
>> >
>> > Regards,
>> >
>> >> > We are currently fixing some small issues with our implementation[1]
>> >>
>> >> Thank you for the link! I'll take a look.
>> >>
>> >>
>> >> Thanks,
>> >> Igor
>> >>
>> >> On Wed, Sep 24, 2014 at 12:48 AM, Lukasz Oles <loles@xxxxxxxxxxxx>
>> wrote:
>> >> > Hi Igor,
>> >> >
>> >> > When we were designing this future (access control for Fuel) there
>> was a
>> >> > discussion about this. We decided to follow OpenStack approach where
>> you
>> >> > authenticate using keystone and then use only token to talk  with
>> >> > services.
>> >> > If you are using fuelclient or UI it's hidden from you as in
>> OpenStack.
>> >> >
>> >> > We are currently fixing some small issues with our implementation[1].
>> >> > Please
>> >> > read the spec. You may suggest some changes which will help you with
>> >> > statistics. Maybe cookies will help?  Vitaly can comment on it.
>> Changing
>> >> > nailgun API for me is the worst solution.
>> >> >
>> >> > [1] https://review.openstack.org/#/c/118284/
>> >> >
>> >> > Regards,
>> >> >
>> >> >
>> >> > On Tue, Sep 23, 2014 at 9:28 PM, Igor Kalnitsky
>> >> > <ikalnitsky@xxxxxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> Hi Lukasz,
>> >> >>
>> >> >> Thank you for the input. Actually I agree with you, but still I
>> think
>> >> >> there's something wrong with our current approach.
>> >> >>
>> >> >> I don't like that we work with keystone directly from UI and Fuel
>> CLI.
>> >> >> I believe there should be a Nailgun API for authenticating users. In
>> >> >> deep of Nail Gun we can use Keystone for authenticating users and
>> >> >> validating tokens, but not vice-versa.
>> >> >>
>> >> >> I mean there's something wrong if we don't provide authentication
>> >> >> abstraction and use keystone directly in both server and client
>> sides
>> >> >> (Nailgun, CLI, UI, Upgrade Script, etc).
>> >> >>
>> >> >> What do you think about it?
>> >> >>
>> >> >> Thanks,
>> >> >> Igor
>> >> >>
>> >> >> On Tue, Sep 23, 2014 at 8:07 PM, Lukasz Oles <loles@xxxxxxxxxxxx>
>> >> >> wrote:
>> >> >> > Guys,
>> >> >> >
>> >> >> > there is no "logout issue". This is REST API. It is stateless.
>> >> >> > There is no such thing like login or logout in REST API. You can
>> only
>> >> >> > get
>> >> >> > authentication token. This token is only valid for a while. After
>> >> >> > some
>> >> >> > time
>> >> >> > it will be outdated and you need to get new one. It doesn't mean
>> that
>> >> >> > user
>> >> >> > login and logout every time, it only means that token is not valid
>> >> >> > anymore
>> >> >> > and you need new one.
>> >> >> >
>> >> >> > In 6.0 token will be valid for 24h, so when you will see new
>> token it
>> >> >> > means
>> >> >> > user started using API again. That's all. You can easily calculate
>> >> >> > when
>> >> >> > user
>> >> >> > started using API and when he ended. You don't need to add
>> >> >> > login/logut
>> >> >> > handlers. It's broken. REST API doesn't work this way.
>> >> >> >
>> >> >> > If we need add new handlers to API because of collecting data it
>> >> >> > means
>> >> >> > you
>> >> >> > are doing something wrong.  Your code should't change anything in
>> API
>> >> >> > workflow.
>> >> >> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > On Mon, Sep 22, 2014 at 12:59 PM, Igor Kalnitsky
>> >> >> > <ikalnitsky@xxxxxxxxxxxx>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi folks,
>> >> >> >>
>> >> >> >> Today I took a look over "logout issue" [1] and figured out that
>> we
>> >> >> >> cannot implement it with current approach.
>> >> >> >>
>> >> >> >> In current approach both login and logout actions are handled by
>> Web
>> >> >> >> UI with direct requests to Keystone server [2].
>> >> >> >>
>> >> >> >> As far as I know, we want to track login/logout actions as a
>> part of
>> >> >> >> anonymous statistic [3], so we need to decide how to avoid this
>> >> >> >> issue
>> >> >> >> and make it fly.
>> >> >> >>
>> >> >> >> I think we need to implement login/logout handlers as a part of
>> >> >> >> Nailgun API. A login handler should receive user credentials and
>> >> >> >> make
>> >> >> >> request to Keystone server in order to retrieve an auth token. A
>> >> >> >> logout handler should mark the token as invalid and forbid any
>> >> >> >> actions
>> >> >> >> with this token.
>> >> >> >>
>> >> >> >> Fuel Web UI should work with login/logout handlers which are
>> part of
>> >> >> >> Nailgun, instead of working with Keystone directly.
>> >> >> >>
>> >> >> >> What do you think about it? Any ideas and suggestions are
>> welcome!
>> >> >> >>
>> >> >> >>
>> >> >> >> [1]: https://bugs.launchpad.net/fuel/+bug/1370964
>> >> >> >> [2]:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> https://github.com/stackforge/fuel-web/blob/master/nailgun/static/js/app.js#L70
>> >> >> >> [3]: https://blueprints.launchpad.net/fuel/+spec/send-anon-usage
>> >> >> >>
>> >> >> >>
>> >> >> >> - Igor
>> >> >> >>
>> >> >> >> --
>> >> >> >> Mailing list: https://launchpad.net/~fuel-dev
>> >> >> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> >> >> >> Unsubscribe : https://launchpad.net/~fuel-dev
>> >> >> >> More help   : https://help.launchpad.net/ListHelp
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Łukasz Oleś
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Łukasz Oleś
>> >
>> >
>> >
>> >
>> > --
>> > Łukasz Oleś
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>