I don’t have the perfect answer for you right now, but I wanted to let you know that we hear you and are actively investigating workarounds. At the moment, I don’t have a solution to provide you, nor can I promise that we’ll be able to provide a solution.
We made this change because data security is of paramount importance to HubSpot. We understand, though, that this change has caused pain and the team is assessing alternative options now. I will update this thread tomorrow on any progress/updates.
My company is also impacted by this change and the lack of appropriate notification. Contacting support simply resulted in us being directed to this forum post with a promise of resolution or workaround tomorrow. I’m a bit worried that our specific use case may not be fully understood, so I would like to lay it out here. ..
Our website is based on HubSpot CMS and contains a form where potential employees can apply to jobs. The application is taken as a hubspot form, and resumes are attached to that form submission as files.
We run a service that receives a webhook from HubSpot every time the form is submitted. It takes the applicants information and shuttles it to our applicant tracking system. The resume file itself is not included in the webhook, rather a link to the resume is included. Our service downloads the resume from HubSpot using that link, uploads the resume to our applicant tracking system, and then uses the HubSpot filemanager API to delete the resume file from HubSpot.
We’ve tried adding our HAPI parameter to the querey string, and we’ve tried sending an OAUTH 2.0 authorization token in the request headers, none of which are accepted by this API endpoint. No matter what we do, the URL redirects our service to a login page meant for a live user, which results in a 503 Service Temporarily Unavailable. No good.
This is a critical business process for us that must be fixed urgently. Your support is greatly appreciated.
We have also been impacted hugely by this change - without any forewarning or explanation of the issue. We moved our CMS to HubSpot from Wordpress in order to improve teh integration of our systems. However, we need to be able to send resumes uplaoded to a CV parser for our recruitment application tracking system. We had a workaround via a partner but this has been switched off.
This has a dramatic impact on our business and questions the viability of moving to HubSpot
Well I just wrote a nice long note explaining the issue we’re having with this new endpoint, and it has been deleted as spam. So I’ll write a shorter version and see if sticks.
We have a service that receives a webhook when a user fills out a form on our HubSpot CMS site. The form includes a file upload. The files URLs now have the new format.
Unfortunately, our service can’t retrieve files anymore since this change. Adding our HAPI to the querey string doesn’t help. Using OAUTH headers on the request doesn’t help. No matter what, our service is sent to a login page meant for a human and dies with a 503.
We have the same problem happening. Our integration webhooks, who are supposedly partners with HubSpot, are having difficulties finding a solution. All the “solutions” we are receiving is to come back to this thread. What HubSpot is telling us is that they made a change, and we just have to accept it. They are not willing to work to find a solution after they made a change when they realized they weren’t securing peoples information aka file URLs.
Whats the point of HubSpot saying they work with other systems when obviously they are not compatable or willing to help? Will all of us having an issue have to say goodbye to HubSpot? I don’t see HubSpot actively working on a solution and am dissapointed. It has been a week since this change has occured and many of our systems are now delayed and we have to workaround manually with a company that preaches automation.
A binary on/off change should have been more proactively communicated and with far greater advance notice. Further, a binary on/off change should have had a transition period.
For example: Upon rollout, there might have been no change for existing customers. However, existing customers might have been given option to elect the feature. After six months, the feature might then have become manadatory for all. This would have allowed customers to test the change and provide needed feedback to Hubspot.
At the moment, our integrations are broken. It appears no thought was given to the use case of programmatic / API-driven download of files from Hubspot. No documented means of authentication allows for programmatic download.
Prior to changing existing functionality, community feedback should be solicited. Had feedback been solicited, the full set of use cases to be supported might have been appreciated prior to implementing such a change.
Can we at least have access to files via FTP? Right now, there is almost no way to actually access the files in a user-friendly way. Had we been given ample notice, we would have downloaded the files before this change.
Hi everyone,
As promised, I wanted to provide an update on where we are with this. The team met today to discuss a couple of possible workarounds for this issue. We don’t have anything concrete to report just yet.
Thank you all for your continued patience as we try to find a solution for this. I’ll provide an update here when we have something actionable to share.
Thanks,
Matt
Hi Everyone,
Thank you for your continued patience as we work out how to address the concerns that have been raised here. I’m pleased to report that we have a solution that will address many of those concerns while still maintaining the secure environment on which HubSpot prides itself.
Starting Monday, November 4th URLs for files uploaded via HubSpot forms will have new authentication support. The current implementation supports browser-based app authentication, which enables a user logged in to HubSpot on a browser to download files via that browser. On Monday, we’ll add OAuth header and HAPIkey support. So you’ll be able to retrieve files using standard authentication mechanisms.
Also on Monday, we’ll start migrating existing file URLs to this new format and support. This migration may take a day or two.
We strive to deliver a secure, powerful platform on which our customers can build great experiences. We appreciate the passionate feedback we’ve received over the past few weeks on this issue.
Thanks,
Matt
Matt, so this “user”, what security within HS will this user have/require? Remember, that for most of the folks that have commented here, this user, will have no other responsibility/duties/needs other than to retrieve the file.
Without a locked down security profile, this is no more secure than whatever the perceived sercurity risks (that I’ve yet to find an explanation behind) that brought on this original change.
For our application, our process is fairly simple (I do understand that others have more complex setups).
Job resume submission -
Applicant fills out a form and attaches file to the form
HS takes the form information and file and emails it internally to our HR representative
Representative opens/retrieves the file.
Easy Peasy… I do not want this person to have any access to any part of the HS platform outside of getting this forms information and file. No access to any dashboards, reports, marketing, social - Nothing, Nada, Zilch.
Scott we did that for a while before we got our automation working. We setup a user who had every permission turned off except files. They could log in to hubspot but basically had a blank UI. They couldn’t even navigate to the Files UI. But they could click the file links in form submission emails and retrieve those.
This wouldnt work for a large company like ours. We aren’t goin to create a large number of logins and expect our team to try to remember another password for a software that is irreleavant to them to use.
Just wanted to mention that I’m cautiously optimistic about the solution being rolled out, barring no additional surprises. The update will allow us to deliver our files as needed with minor additional build. We can handle that. We also care about securing the data in these files. We do want to be able to tell everyone using this system that their information is protected.
That said, HubSpot really needs to work on a few things here:
External communication. When I first called HubSpot about this issue, your support told me this change was communicated to us weeks ago. A post on this form does not constitute communication! Anything that has the potential to adversely affect existing build must be communicated via email to admins, and earlier than a few weeks time (to find and secure developers to update our build). This change wasn’t even on your product update blog! You have to understand that businesses have lost real money due to this negligance. This is not just a bug, an annoyance, this is a monetary loss to the businesses you’re supposed to be serving. It will affect livelihoods. What’s more, you’ve also completely obliterated our trust. What other core functionality will you suddenly change without warning or workaround? And if you tell us it will never happen again, why should we trust your answer?
Internal communication. I normally really like HubSpot support. This time around, it’s clear the change completely caught them offguard too. One person told me the workaround is to programmatically download the file and store it on a separate server, despite that not actually being possible. Another told me there is no planned fix, that this is final state, though clearly a fix was being planned. Today a third rep told me he asked around and found a third-party (paid) app to support our needs, despite your solution being annouced earlier this week (making his idea irrelevant). In short: get it together.
Emailed attachments in workflows. Reading through this chain, I can see much of the pain of this update would have been mitigated if HubSpot allowed attachments to emails sent via workflows. For example, we could have set up a system where submitted forms generated emails (with attachments) that got sent to a unique mailbox, paired with separate automation to upload those emailed attachments to a seperate and internally accessible location. That could have worked for us, but there’s apparently no way to send email attachments via workflow. Look at the comments in this thread. So many people are just emailing these files as attachments. Why not listen to your users and implement this basic feature?
As you’ve likely noticed, new files have the new URL format as of Monday, and existing files are in the process of being moved to the new format.
At the same time, we’re completing testing of the authenticated download functionality, and will be providing updates and documentation once that is complete. At that time, the files at these new URLs will be accessible via OAuth headers (with the correct scope), API key, and standard, browser authentication.
Matt / @mwelch Tried as of today and it seems that no consideration was given for setting up a user account, for file access only??
I have a test user that I have given them NO permissions in the Hubspot portal. Yet, upon logon this user has acccess to:
Activity Feed
Conversations
Inbox and Chatflows
Files ( HUGE security hole!!! )
Deals - Can create
Tasks - Can Create
Service - Can create tickets
Reports
Analytics Tools
Dashboards
View Reports
1 How can a user that has effectively been given NO access rights, be able to access so much of the system? The files portion is a gaping hole. They could effectively delete every file in the website…!!!
#2 How are we to access these files, SECURELY. Since security was the motivating factor in this project, there has to be a way to do exactly that.
So I’ll write a shorter version and see if sticks. 