You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am facing errors from Webmock and VCR where specs fail with an unhandled web request error. e.g. UnhandledHTTPRequestError or NetConnectNotAllowedError.
During my investigation I noticed that those unhandled web requests are caused by the download! method. This method gets called if an external_url is present. Which is here the case.
Question
My goal is to have an offline test suite, therefore, I was a bit surprised about this behavior, since I set enable_processing to false.
I solved the offline approach by mocking all requests:
Currently, I am unsure if this is the best approach or if carrierwave should handle this automatically depending on the enable_processing setting. Especially since setting enable_processing to false causes an early exit anyway.
The text was updated successfully, but these errors were encountered:
I'm not sure with the best practices of testing carrierwave too, but I'm currently
disabling ssrf_filter by configuring skip_ssrf_protection? with a custom downloader only for test
Problem
Hello everyone 👋
I am facing errors from Webmock and VCR where specs fail with an unhandled web request error. e.g.
UnhandledHTTPRequestError
orNetConnectNotAllowedError
.During my investigation I noticed that those unhandled web requests are caused by the
download!
method. This method gets called if anexternal_url
is present. Which is here the case.Question
My goal is to have an offline test suite, therefore, I was a bit surprised about this behavior, since I set
enable_processing
tofalse
.I solved the offline approach by mocking all requests:
SsrfFilter::DEFAULT_RESOLVER
Add way to globally disable filter arkadiyt/ssrf_filter#33 (comment)Currently, I am unsure if this is the best approach or if carrierwave should handle this automatically depending on the
enable_processing
setting. Especially since settingenable_processing
tofalse
causes an early exit anyway.The text was updated successfully, but these errors were encountered: