fuel-dev team mailing list archive

[Lukasz Oles <loles@xxxxxxxxxxxx>]

On Fri, Sep 26, 2014 at 7:39 AM, Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx> wrote:
> Actually, it's far from what we have now. If I understand correctly
> our JavaScript code [1], we just remove token from the browser storage
> and that's all. I mean, the token is removed from browser but still
> valid and can be use to sign API requests.

Igor, I was answering to Mikes suggestion "Logout can be as simple as
token removal from client cache (UI or CLI, no matter) " And as you
showed  in the code it works that way. Token is deleted from cache.

>
> So I propose to fix it as a part of Lukasz's blueprint [2].
>
> [1]: https://github.com/stackforge/fuel-web/blob/a8226df578e63031d8c7189814d03d6f2ffee29e/nailgun/static/js/app.js#L181
> [2]: https://review.openstack.org/#/c/118284/
>
>
> Thanks,
> Igor
>
> On Fri, Sep 26, 2014 at 10:15 AM, Alexander Kislitsky
> <akislitsky@xxxxxxxxxxxx> wrote:
>> 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:
>>>
>>> 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.
>>> Please someone explain to me why do we want to track logout action by
>>> stats collector
>>> 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.
>>> 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.
>>> 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
>>>
>>
>
> --
> 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ś