On Fri, Sep 26, 2014 at 7:39 AM, Igor Kalnitsky <ikalnit...@mirantis.com> 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 > <akislit...@mirantis.com> 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 <mscherba...@mirantis.com> >> 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 <ikalnit...@mirantis.com> >>> 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 <lo...@mirantis.com> wrote: >>>> > Hi Igor, >>>> > >>>> > On Wed, Sep 24, 2014 at 8:58 AM, Igor Kalnitsky >>>> > <ikalnit...@mirantis.com> >>>> > 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 <lo...@mirantis.com> >>>> >> 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 >>>> >> > <ikalnit...@mirantis.com> >>>> >> > 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 <lo...@mirantis.com> >>>> >> >> 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 >>>> >> >> > <ikalnit...@mirantis.com> >>>> >> >> > 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@lists.launchpad.net >>>> >> >> >> 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@lists.launchpad.net >>>> 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@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~fuel-dev >>> More help : https://help.launchpad.net/ListHelp >>> >> > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : fuel-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp -- Łukasz Oleś -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp