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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: >> > Hi Igor, >> > >> > On Wed, Sep 24, 2014 at 8:58 AM, Igor Kalnitsky < >> [email protected]> >> > 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 <[email protected]> >> 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 >> >> > <[email protected]> >> >> > 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 <[email protected]> >> >> >> 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 >> >> >> > <[email protected]> >> >> >> > 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 : [email protected] >> >> >> >> 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 : [email protected] >> 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 : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
