search

node-oauth / node-oauth2-server

🚀 The successor to oauthjs/oauth2-server. 🔒 Complete, compliant, maintained and well tested OAuth2 Server for node.js. Includes native async await and PKCE.
https://www.npmjs.com/package/@node-oauth/oauth2-server
MIT License
286 stars 39 forks source link

fix: explicitly support array of strings for AuthenticateHandler.options #309

Closed dhensby closed 1 month ago

dhensby commented 1 month ago

Summary

In #267 some changes were made for compliance reasons where scopes should be treated as strings for our OAuth interfaces but as arrays of strings for internal purposes. As part of that change, we accidentally made the scope prop for the authenticate method only support strings.

This change remediates any potential backwards compatibility changes from v5.0 to v5.1

Linked issue(s)

307 & #267

Involved parts of the project

authenticate handler

Added tests?

✅

jankapunkt commented 1 month ago

We should make clear that array scopes need to be trimmed etc. We do that with strings in parseScope but we do not validate if it's an array. Could there be any issues involved with array scopes?

dhensby commented 1 month ago

We can introduce a "validate scopes" function that validates an array of scopes - I did think about this, but decided that would lean this towards a "feature" rather than a "fix" (and I wanted to go for a fix here).

Because this array of scopes if provided by the developer (or should be!) then I don't think there's such a risk to have malformed arrays of scopes. Do we validated the arrays of scopes that are provided in any other part of the library?

dhensby commented 1 month ago

Just to touch on the typings too - we could just put it as scope?: string[] if we feel use of a string is to be deprecated, because there's no need for the typings to include deprecated values and clearly the typings hadn't been causing problems for people up to now 😅

dhensby commented 1 month ago

I've made the small change which essentially reverts the change from #305 so that the typings reflect our ideal implementation.

I think that keeps things straightforward for implementors in TS and also means it's less likely users will need to perform refactors when we do remove the string support if they've been following the types.

Lordfirespeed commented 1 month ago

Any blockers here/on a release? At the moment I'm relying on 

"foo" as unknown as string[]

Which is a bit of a code-smell, to say the least 😅

jankapunkt commented 1 month ago

@Lordfirespeed I'm back at the office tomorrow and will then release an RC that reflects on all recent PRs.

Lordfirespeed commented 1 month ago

@Lordfirespeed I'm back at the office tomorrow

Awesome! Thanks very much ♥️ hope your holidays have been restful & enjoyable