Skip to content

Conversation

@ahme-dev
Copy link

Adds the ability to get an account by username, alongside the normal id. As discussed in #264

@ahme-dev ahme-dev changed the title feat: add account getting by username add username to get account Jan 27, 2025
@ahme-dev ahme-dev changed the title add username to get account Add username to get account Jan 27, 2025
Comment on lines +9 to +14
type AccountGetterParams struct {
AccountID *int
Username *string
}

func AccountGetter(store data.AccountStore, params AccountGetterParams) (*models.Account, error) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't seen structs used for params, so let me know if this should be changed

@ahme-dev ahme-dev marked this pull request as ready for review January 27, 2025 13:54
Copy link
Member

@cainlevy cainlevy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @ahme-dev, thanks for your patience. This looks good! I have one small question before I'm ready to approve.

Copy link
Member

@cainlevy cainlevy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ahme-dev

@cainlevy
Copy link
Member

cainlevy commented Feb 7, 2025

@ahme-dev Would you take a look at the failed tests in https://github.com/keratin/authn-server/actions/runs/13155722367/job/36867948456?pr=265?

I believe the failed lint is a different issue.

Handle(handlers.PostAccountsImport(app)),

route.Get("/accounts/{id:[0-9]+}").
route.Get("/accounts/{id}").
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cainlevy, one of the tests (for available account) fails because this overrides the public route "/accounts/available". Any suggestions to work around this? Can't use the older [0-9] since it rejects accept emails. I think we ideally want to put the overriden route above this route definition, but being in separate files, it might be difficult.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes that is awkward.

I think it's worth trying to register public routes before private routes to fix this. It sounds like the test case, as written, will ensure it remains that way. If we later run into a new issue that implies a need to reverse the order again, we'll find a new kind of solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants