KegTap issueshttps://git.mittelab.org/proj/kegtap/-/issues2020-11-07T10:54:11Zhttps://git.mittelab.org/proj/kegtap/-/issues/27Evaluate effort to switch to pluggy2020-11-07T10:54:11ZAljaž Srebrničpresidente@mittelab.orgEvaluate effort to switch to pluggyHow difficult would it be to switch from our plugin implementation to [pluggy](https://pluggy.readthedocs.io/en/latest/)? Worth the effort?How difficult would it be to switch from our plugin implementation to [pluggy](https://pluggy.readthedocs.io/en/latest/)? Worth the effort?https://git.mittelab.org/proj/kegtap/-/issues/25Better logging2020-11-29T22:55:31ZPietro SaccardiBetter loggingCurrently the logging is done only via uvicorn. We can use better methods that make debugging way easier: https://medium.com/1mgofficial/how-to-override-uvicorn-logger-in-fastapi-using-loguru-124133cdcd4eCurrently the logging is done only via uvicorn. We can use better methods that make debugging way easier: https://medium.com/1mgofficial/how-to-override-uvicorn-logger-in-fastapi-using-loguru-124133cdcd4ePietro SaccardiPietro Saccardihttps://git.mittelab.org/proj/kegtap/-/issues/24Better UX in handling configuration2020-11-06T22:25:20ZAljaž Srebrničpresidente@mittelab.orgBetter UX in handling configurationIf a plugin fails to parse its config, explicitly warn user that it's using defaults. This will avoid errors where the plugin name is misspelled.If a plugin fails to parse its config, explicitly warn user that it's using defaults. This will avoid errors where the plugin name is misspelled.https://git.mittelab.org/proj/kegtap/-/issues/21Dynamic loading of plugin frontend components2020-05-21T20:03:13ZSonia ZorbaDynamic loading of plugin frontend components# Dynamic loading of plugin frontend components
Since KegTap is composed by pluggable modules, it seems natural to implement the UI in a modular way too.
Plugins are activated at runtime based on kegtap.toml configuration file, so it w...# Dynamic loading of plugin frontend components
Since KegTap is composed by pluggable modules, it seems natural to implement the UI in a modular way too.
Plugins are activated at runtime based on kegtap.toml configuration file, so it would be nice to have UI pieces loaded at runtime too, at least for plugins which are not part of the kegtap core (e.g. `ChallengeManager` is someway mandatory, while `FindUser` and other plugins composing the base challenges are not; correct me if I'm wrong).
I think a proper way to handle this is using [Vue.js Async Components](https://vuejs.org/v2/guide/components-dynamic-async.html) (components which are loaded using an AJAX call). We could add an API endpoint for retrieving plugin UI.
I implemented this idea in the first UI prototype I pushed (checkout ui branch). When you execute `npm run serve` it uses mocked AJAX calls, so you can see it in action even if the endpoint for retrieving plugin UI is not implemented yet.
However, I have 2 main concerns about this approach.
The first one is about testability. I'm not expert in unit testing of front-end code, but I think having pieces of the UI loaded in this way makes testing harder.
The second one is about how the retrieval of additional JavaScript logic required by each plugin is handled. Indeed, I consider the way I made it work a dirty hack, since it involves the serialization of a function [inside a JSON string](https://git.mittelab.org/infra/kegtap/-/blob/ui/kegtap-ui/src/api/mock/data/findUser.json) and then the use of [eval](https://git.mittelab.org/infra/kegtap/-/blob/ui/kegtap-ui/src/ChallengeManager.vue#L40) for obtaining the function from it. I have concerns about maintainability, readability and also security. But maybe I have to learn more about how Vue.js async components work, so give me a few days to investigate this a little better.
An alternative approach would be including the required UI pieces at build time, based on all available plugins. I tried to put them in the contrib_plugins folder and load them from the kegtap-ui folder but I received the error `No ESLint configuration found in contrib_plugins`. It is probably just a matter of configuration but I would like to hear what do you think about these 2 approaches before spending more time in trying to make it work.https://git.mittelab.org/proj/kegtap/-/issues/20Wishlist for backend features2020-06-07T19:20:25ZPietro SaccardiWishlist for backend featuresEntries that are decided upon can be converted to a separate issue.
- **User-side rate limiting.**
Password resets and login tries should be rate limited via IP and username.
- **FreeIPA rate limiting.**
Usage of FreeIPA APIs sh...Entries that are decided upon can be converted to a separate issue.
- **User-side rate limiting.**
Password resets and login tries should be rate limited via IP and username.
- **FreeIPA rate limiting.**
Usage of FreeIPA APIs should also be rate limited.
- **FreeIPA re-authenticate mechanism.**
Do Kerberos credentials expire? Or rather, does the FreeIPA session expire before the credentials? Should we allow the FreeIPA client to login again within the same process?
- [x] Email should be sent asynchronously.
Page load should not be blocked while waiting for the SMTP exchange.
- **User could operate using their own authenticated IPA session.**
This can happen in the circumstances in which the login method is known to FreeIPA (e.g. Kerberos, user+pass). Is this really useful? Does it significantly increase security?
- [x] We could probably use an [APIRouter](https://fastapi.tiangolo.com/tutorial/bigger-applications/#apirouter) instead of using the FastAPI app... Benefits include
* having only one /docs endpoint (since it's the same app)
* you can put a `Depends` for the [whole include](https://fastapi.tiangolo.com/tutorial/bigger-applications/#include-an-apirouter-with-a-prefix-tags-responses-and-dependencies)
* the syntax is basically the samehttps://git.mittelab.org/proj/kegtap/-/issues/19Wishlist for user area capabilities2020-02-18T16:47:49ZPietro SaccardiWishlist for user area capabilitiesEntries that are decided upon can be converted to a separate issue.
- **Users can change their email.**
Should it be allowed? Is there any service where an email change will mess the service's authentication.
- **User can change the...Entries that are decided upon can be converted to a separate issue.
- **Users can change their email.**
Should it be allowed? Is there any service where an email change will mess the service's authentication.
- **User can change their password.**
Should this be a fast lane to #17?
- **User can't set a password from the pwned passwords list.**
In general, there should be a nice "password validation tool". I presume that there is something online that does a real entropy measure?
- **User can flag their account as compromised.**
We could have a link to flag the user as compromised, prompting a notification to the eNOC team.
- **Alternate authentication methods.**
SAML (SSO)? JWT? Kerberos?https://git.mittelab.org/proj/kegtap/-/issues/1First user activation2020-02-18T16:29:17ZAljaž Srebrničpresidente@mittelab.orgFirst user activationHas to have interface to easily activate new users. This sends an email to the associated address with a temporary reset code to set a password.
Bonus: A wizard where the user can add SSH keys and activate 2FA and request a personal cer...Has to have interface to easily activate new users. This sends an email to the associated address with a temporary reset code to set a password.
Bonus: A wizard where the user can add SSH keys and activate 2FA and request a personal certificate.