Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
I think it can be just a bug - remove token on Fuel UI logout. None of CLI commands in OpenStack deletes token. I believe it should be considered as bug, and I would file one to OpenStack. I think Fuel CLI has to delete the token. On Tue, Sep 30, 2014 at 1:45 AM, Lukasz Oles lo...@mirantis.com wrote: Ok, so I checked how it looks in OpenStack. Horizon deletes token and it's doing it during logout and login if token wasn't deleted earlier. None of CLI commands in OpenStack deletes token. With such knowledge, what do you want to do? We will update blueprint accordingly. Regards, On Sat, Sep 27, 2014 at 1:59 PM, Mike Scherbakov mscherba...@mirantis.com wrote: DELETE /v2/tokens/token we can treat as bug, I hope it's fairly simple to implement on both JS and Python CLI side. Mike Scherbakov #mihgen On Sep 27, 2014 5:30 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: On Fri, Sep 26, 2014 at 12:39 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: 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. I thought we shouldn't spam openstack-dev ML with such questions, since it's about our internal design. Fuel is a stackforge project, so it's fine to discuss Fuel specific topics in openstack-dev. Having [Fuel] in subject line is enough to allow people to filter such threads as they see fit. -DmitryB -- 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ś -- 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
On Tue, Sep 30, 2014 at 8:28 AM, Mike Scherbakov mscherba...@mirantis.com wrote: I think it can be just a bug - remove token on Fuel UI logout. https://bugs.launchpad.net/fuel/+bug/1375622 None of CLI commands in OpenStack deletes token. I believe it should be considered as bug, and I would file one to OpenStack. I think Fuel CLI has to delete the token. I would like to do some more research on it. I think it's not done by OS tools because CLI is low level tool and all actions should be done manualy. On Tue, Sep 30, 2014 at 1:45 AM, Lukasz Oles lo...@mirantis.com wrote: Ok, so I checked how it looks in OpenStack. Horizon deletes token and it's doing it during logout and login if token wasn't deleted earlier. None of CLI commands in OpenStack deletes token. With such knowledge, what do you want to do? We will update blueprint accordingly. Regards, On Sat, Sep 27, 2014 at 1:59 PM, Mike Scherbakov mscherba...@mirantis.com wrote: DELETE /v2/tokens/token we can treat as bug, I hope it's fairly simple to implement on both JS and Python CLI side. Mike Scherbakov #mihgen On Sep 27, 2014 5:30 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: On Fri, Sep 26, 2014 at 12:39 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: 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. I thought we shouldn't spam openstack-dev ML with such questions, since it's about our internal design. Fuel is a stackforge project, so it's fine to discuss Fuel specific topics in openstack-dev. Having [Fuel] in subject line is enough to allow people to filter such threads as they see fit. -DmitryB -- 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ś -- Mike Scherbakov #mihgen -- Ł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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
DELETE /v2/tokens/token we can treat as bug, I hope it's fairly simple to implement on both JS and Python CLI side. Mike Scherbakov #mihgen On Sep 27, 2014 5:30 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: On Fri, Sep 26, 2014 at 12:39 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: 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. I thought we shouldn't spam openstack-dev ML with such questions, since it's about our internal design. Fuel is a stackforge project, so it's fine to discuss Fuel specific topics in openstack-dev. Having [Fuel] in subject line is enough to allow people to filter such threads as they see fit. -DmitryB -- 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
Hi all, @Mike, 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. I thought we shouldn't spam openstack-dev ML with such questions, since it's about our internal design. 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. I guess the topic is over. I mean, we discussed it. If we're going to use Keystone's service discovery feature - I'm ok with it; it may help us to get rid of hardcoded IP/Port values. @Lukasz, This is how it works now. If you press logout on browser, token is deleted. 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. 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
Hi all, @Alexander If you log off, the UI can also revoke the token using DELETE /v2/tokens/token Best regards, Kamil Sambor On Fri, Sep 26, 2014 at 9: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: 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 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
As Kamil sugested we can use keystone API do delete token if it's required. But if you really want to increase Fuel Master node security I propose to implement HTTPS. We even have blueprint[1] for this. Sebastian is author of it and he can provide more info. If you really need to know when tokens are created and deleted(if we add this) you can use keystone event mechanism[2]. We already have rabbitmq and oslo.mesasging in the Fuel. It's even better because it's done in async way. [1] https://review.openstack.org/#/c/119330/ [2] http://docs.openstack.org/developer/keystone/event_notifications.html Regards, On Fri, Sep 26, 2014 at 7: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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
Lukasz, HTTPS is fine and MUST be implemented ASAP, but it doesn't solve the issue. When I click Logout I'm expecting that a token will be revoked, so nobody can use it to sign requests if it was stolen. It's about security. It's a behaviour that I expect as user. I don't want make manual requests to Keystone in order to revoke token - I want it out of box. So what's the problem to implement it within mentioned blueprint? Thanks, 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
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 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 javascript:; wrote: Hi Igor, On Wed, Sep 24, 2014 at 8:58 AM, Igor Kalnitsky ikalnit...@mirantis.com javascript:; 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 javascript:; 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
I can answer 2 questions here. See below On Thu, Sep 25, 2014 at 9:53 PM, 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. This is how it works now. If you press logout on browser, token is deleted. 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. Wiith current approach all services (ostf and keystone) are protected. Service/endpoint discovery will be added in 6.0 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
Hi Lukasz, We decided to follow OpenStack approach where you authenticate using keystone and then use only token to talk with services. If some approach is used by OpenStack, it doesn't mean it's right. There were reasons to implement this way in OpenStack, and I don't see such reasons in Fuel (at least now). I mean, in OpenStack we have various services which interact with each other. Obviously, such interactions must be signed by some token. Therefore, we have a Keystone - a one source of truth. In Fuel we need authentication only for Nailgun and we don't need it for other parts of Fuel, right? If so, we don't need a separate authenticating service. Let's use Nailgun as a self-sufficient RESTful service. It will give us some benefits. 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. 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ś -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
I agree with Lukasz. On Wed, Sep 24, 2014 at 12: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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
Hi all, I started implement login/logout handlers for Nailgun. I'd be grateful if python team make review of my patchset [1], since I may do something wrong. So feedback is very welcome! [1]: https://review.openstack.org/#/c/123444/ - Igor On Mon, Sep 22, 2014 at 4:47 PM, Alexander Kislitsky akislit...@mirantis.com wrote: Definitely, login and logout API calls must be in Nailgun API. For now we can implement collecting of anonymous statistics without info about login/logout and begin to consider them after login/logout will be implemented in the Nailgun API. On Mon, Sep 22, 2014 at 4: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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
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ś -- 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
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ś -- 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
Re: [Fuel-dev] Login and Logout actions are absent in Nailgun
Interesting area of discussion. With processes running (anytime, possibly via cron etc) on any of N nodes on behalf of the end-user, using tokens that'll expire whenever they expire, to authorize doing work for that user... how can you say they're logging in and/or logging out? From my perspective... when the end-user comes and goes from their horizon sessions is orthogonal to whether keystone should allow or disallow activities. I hope this correlates with the current thinking on how to proceed. Kind regards, -Paul Reiber Phone: (650)430-7926 Email: p...@reiber.org Web: http://bit.ly/reiber “In the beginning of a change the patriot is a scarce man, and brave, and hated and scorned. When his cause succeeds, the timid join him, for then it costs nothing to be a patriot.” -Twain On Tue, Sep 23, 2014 at 2: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ś -- 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
