Add event to customize app password token generation

[CTabou]

Summary

We want to enable applications to generate their own device and session authentication tokens by introducing an event that fires immediately after token creation, allowing apps to supply a token generated with their own rules (e.g., format, length, charset) before it is persisted.

TODO

• [x] Add OCA\Settings\Events\AfterAuthTokenCreatedEvent (token-only payload with getter/setter).
• [x] Inject OCP\EventDispatcher\IEventDispatcher into AuthSettingsController and dispatch the event after generating $token, before persisting the device token.
• [x] Update the apps/settings Composer classmap (dump autoload) to expose the new event.
• [x] Add unit tests in apps/settings/tests/Controller/AuthSettingsControllerTest.php.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• [x] Tests (unit, integration, api and/or acceptance) are included
• [x] Screenshots before/after for front-end changes
• [ ] Documentation (manuals or wiki) has been updated or is not required
• [ ] Backports requested where applicable (ex: critical bugfixes)
• [ ] Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• [ ] Milestone added for target branch/version (ex: 32.x for stable32)

Screenshots

Before

After

[come-nc]

Can you explain the usecase for allowing apps to control token generation? Is it to generate something somehow more secure? Would it make sense to instead improve/extend the token generation in server?

The new file is missing the license, apart from that the code looks good.

[CTabou]

Thanks for your feedback!

A concrete use case is that Nextcloud currently generates tokens like MaoFz-njK2i-pgq5o-MsYdn-8GXYi, but some of our enterprise customers have internal security policies requiring stronger tokens — for instance, a minimum length of 40 characters and the inclusion of special characters such as @, #, or $.

By allowing applications to customize token generation through this event, they can enforce these stricter rules (length, charset, or format) without modifying the core token generation logic in the server. This provides more flexibility for environments with advanced compliance or security requirements.

I’ll also add the missing license headers to the new files — thanks for pointing that out!

[github-actions[bot]]

Hello there, Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[provokateurin]

I'm fine with the code, but feel like it would make more sense to add some options in the server to control the token generation.

[CTabou]

Thanks for the feedback! I agree that adding options on the server side to control token generation could be useful. For this PR, would you be okay merging it as it is, and I can follow up with a separate PR introducing configurable options?

[provokateurin]

Sure @CTabou!

[provokateurin]

Can you rebase onto the master branch, squash all commits and fix the DCO?

[provokateurin]

@CTabou please don't update the branch unless there are merge conflicts. It is not necessary and only wastes CI time, because we have to restart it completely.