Hello,
TLDR;
When Authentication Type is set to Personal Access Token, the “Bearer” prefix is not sent in the Authorization Request Header.
Details:
When the Authentication type is set to Personal Access Token, I’m able to establish a connection by entering the token.
However when the API request is sent from the Custom Connector designer, the request fails. The request headers show that the Authorization header does not have “Bearer” appended to it.
I changed the Authentication type to Bearer. But when I connected, I had to enter “Bearer” followed by the token to create the connection.
This time, when the POST request was sent, it worked without any issues.
Hi Andy,
Thank you for reporting this behavior. Your observation is an accurate description of the current behavior around the Personal Access Token authentication type.
Your first observation, that you can make a connection using your token (without the “Bearer” prefix), but then subsequent requests will fail with a 401 response is behavior that we are actively working to improve. The underlying reason this is happening is that we do not have an endpoint to test the connection against before you make a direct request, so we have no way of knowing if the connection is valid. This is the case for authentication types that rely on request authentication patterns like Basic, API Key, Personal Access Token and Custom. OAuth related authentication types will be able to confirm successful authentication based on the token generation process.
You did discover the solution to getting a 401 response issue, which is to manually enter the Bearer prefix before entering your token during the connection creation process, but we understand that this is not an ideal solution.
Moving forward, our plan is two-fold
- Ask the user for an endpoint to test their connection against. We would then ping this endpoint and analyze the response to make sure that the connection is valid and then subsequently ping the endpoint after connection to ensure continued validity.
- Add the ability to specify a token prefix that can automatically injected before the token. This would mean that during the authentication setup, you could specify “Bearer” (or another prefix as needed by the provider) that would be injected before the provided token. Users would only have to add their token during the connection creation process.
I’d be interested in hearing your feedback on if this plan would suffice for your use case?
Hi @Ramsay_Grove ,
I think the enhancements you are planning make sense to me.
Also I have a slightly different take on this.
I see that you already have the feature to generate payloads only after a successful 200 request is made by the user.
Similarly, would it be possible to prevent the user from authenticating unless they have defined the first endpoint request.
That way when the user tries to authenticate, you already have the first request that you can use to validate the header prefix.
The other challenge i can think of here is as follows:
What if the endpoint that you are asking the user to validate is a complex POST request? What if the user does not have a simpler GET request endpoint to provide for your evaluation?
Thanks for getting back to me. I also have other suggestions regarding composing complex request bodies. I hope we can make some time to discuss.
Regards,
Andy
1 Like
Hi @AndyMenon,
I would be hesitant to restrict a user from being able to set up authentication without an endpoint request first. What I want to do is make the testing endpoint built into the authentication flow so that it is a natural progression of authentication process.
The testing endpoint would have to be restricted to GET calls since allowing a user to use a POST request to validate the connection could result in a lot of issues, especially if we are call that endpoint on a schedule to check the connection status.
I would be happy to talk to you about your suggestions! I will send you a direct message and we can schedule a call together.
Thanks,
Ramsay
