-
Notifications
You must be signed in to change notification settings - Fork 66
zapier convert: Add support for basic auth mapping #200
Conversation
Most of these tests failed because I added heading and trailing spaces to the trigger template. This commit fixes them by removing the heading and trailing spaces with .trim() method before making assertion in the test code. This is temporary because I think we can use a tool like Prettier to format the generated code automitcally, so we don't have to manually format it in the templates, which is such a pain.
If no auth, there should be no `authetication` section in the app definition nor `authencation.js`.
We were assuming basic auth is always username and password when generating test code. The right thing to do is to use `auth_fields`. This commit only addresses the issue for basic auth. We should really do this for all the auth types.
@@ -1,4 +1,7 @@ | |||
<% if (before && !session && !oauth) { %>const maybeIncludeAuth = (request, z, bundle) => { | |||
<% if (customBasic) { %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I use the term "custom basic" to indicate a basic authentication that does not use username and password as user-facing authentication fields.
@@ -120,7 +120,7 @@ describe('convert render functions', () => { | |||
const wbDef = definitions.noAuth; | |||
return convert.renderIndex(wbDef) | |||
.then(string => { | |||
string.should.containEql('authentication: {}'); | |||
string.should.not.containEql('authentication:'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally, we generated an empty {}
when a WB app doesn't have auth. The right way is not to include an authentication
section at all if the WB app doesn't have auth. Refer to AppSchema.
src/tests/utils/convert.js
Outdated
@@ -202,14 +202,12 @@ describe('convert render functions', () => { | |||
|
|||
return convert.getHeader(wbDef) | |||
.then(string => { | |||
string.should.eql(`const maybeIncludeAuth = (request, z, bundle) => { | |||
string.trim().should.eql(`const maybeIncludeAuth = (request, z, bundle) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.trim()
is to remove leading and trailing spaces generated by the template. I leave the generated code unformatted because formatting the code in the templates is hard and makes the template unreadable. I think I'll make another PR that uses Prettier to format the generated code.
@@ -95,7 +95,7 @@ const getAuthType = (definition) => { | |||
}; | |||
|
|||
const hasAuth = (definition) => { | |||
return getAuthType(definition) !== 'custom' || !_.isEmpty(definition.auth_fields); | |||
return getAuthType(definition) !== 'custom' && !_.isEmpty(definition.auth_fields); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes the logic determining if an app has auth.
}`; | ||
break; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the generated test code, we were assuming basic auth is always username and password, which is not true. We should really take advantage of auth_fields
instead.
Will try to test this out a bit tomorrow. Off the cuff, does this handle a case where say an app only has an |
@bcooksey exactly that case! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a small bug. I'm not quite sure how to cover for that in tests, as you'd need to actually execute the generated code. If you have a quick win, go for it, otherwise I think the test coverage here is good enough.
scaffold/convert/header.template.js
Outdated
}; | ||
const username = replaceVars(mapping.username, bundle); | ||
const password = replaceVars(mapping.password, bundle); | ||
const encoded = `${username}:${password}`.toString('base64'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
toString()
on a string won't encode in JS like you'd hope. Need to wrapper in a Buffer I believe.
> 'asdf:'.toString('base64')
'asdf:'
> new Buffer('asdf:').toString('base64')
'YXNkZjo='
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR handles the case where a WB app with basic authentication has an authentication mapping. In CLI, we don't have authentication mappings. Instead, we just let users freely define their authentication in a function. So when converting a WB app like this, we need to use
custom
auth type and mimic the mapping of the auth fields in the authentication function.Example app to try out: 80444