blueimp

5 ms·

1. 1.▲
   by blueimp 7y ago

   You're welcome! :)
2. 2.▲
   by blueimp 7y ago

   For local automated testing of mobile browsers on both iOS and Android you probably want to have a look at https://appium.io/ , which uses the Webdriver protocol. If you want to run the same tests against both mobile and des
3. 3.▲
   by blueimp 8y ago

   Well you can use the provided images without forking and they both support running Chrome/Firefox headless without X. But since I'm building this in my personal time there's no professional support nor a guarantee that it won
4. 4.▲
   by blueimp 8y ago

   Hey aboutruby, the way to use this project is the following: 1. Checkout the repo 2. Follow the README to setup the different browsers 3. Run the tests against the included sample app 4. Replace the sample app with your own app. That last p
5. 5.▲
   by blueimp 8y ago

   Any Framework (including WebdriverIO) that uses the W3C Webdriver API or the older Selenium JSON Wire Protocol requires the appropriate driver for each browser. In my opinion that's not a disadvantage, since the Webdriver API is a W3C
6. 6.▲
   by blueimp 8y ago

   While Docker definitely supports tagging versions, I've decided to not tag the example images for now. The main reason for this is that it would be very difficult to properly express what a version stands for. e.g. there are multiple c
7. 7.▲
   by blueimp 8y ago

   I'd say it's definitely hard to write cross-browser automated tests that are not flaky. Some of that is due to unreliably implementations of the Webdriver API (or the previous Selenium JSON Wire protocol) in the different drivers.
8. 8.▲
   by blueimp 8y ago

   I think puppeteer is an interesting project, but right now it's Chrome-only and therefore pretty much useless for cross-browser testing. Even with support for Firefox, it would still lack support for Safari Desktop, Safari Mobile, Inte
9. 9.▲
   by blueimp 8y ago

   Hey Vinni, you can definitely use this project and the containerized versions of Chrome/Firefox on CI - in fact that's its primary use case. The way this project is setup is to use the chromedriver/geckodriver servers directl
10. 10.▲
    Show HN: Wdio – Docker setup for WebdriverIO

    49 points by blueimp 8y ago|14 comments
11. 11.▲
    by blueimp 8y ago

    Since this is about vulnerabilities in a third-party dependency (ImageMagick/Ghostscript), the recommendation in the blog post to use the GD library instead (what the image_library 0 setting does) is not very sound, as libgd also had a
12. 12.▲
    by blueimp 8y ago

    If the upload directory is securely configured, no. Please refer to the vulnerability documentation here to see if you are affected: https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...
13. 13.▲
    by blueimp 8y ago

    Please refer to the vulnerability documentation here to see if you are affected: https://github.com/blueimp/jQuery-File-Upload/blob/master/VU...
14. 14.▲
    by blueimp 8y ago

    That was my thought as well. I think one of the reasons nobody reported this earlier was that people simply assumed that .htaccess support was the default - Larry Cashdollar, the security researcher, also confirmed this: https://
15. 15.▲
    by blueimp 8y ago

    I do think that my project is responsible and not Apache, since I provided sample code that was not secure by default when used in a default Apache configuration as is. However I wish Apache would have changed their default config in a way
16. 16.▲
    by blueimp 8y ago

    I agree with you that this would be the safer route. For a production file upload service, file uploads should ideally stored in a specialized blob store, e.g. Amazon S3 or Google Cloud Storage. However the PHP code was written as easy-to
17. 17.▲
    by blueimp 8y ago

    Thanks! Comments like yours are what keeps me motivated to continue contributing to open source software. But although the title is somewhat click-bait, I still think this counts as a vulnerability in my project, since there is a possible c
18. 18.▲
    by blueimp 8y ago

    Thanks! I already got a helpful pull request for the main README.me that I've updated by now with - Security-related releases on top of the main page: https://github.com/blueimp/jQuery-File-Upload#%EF%B8%8F-secu...
19. 19.▲
    by blueimp 8y ago

    Although I agree with you in a general sense, in this case there was no blacklist mistakenly used. If the server is configured to serve uploaded files securely, it is feasible to allow all file types for upload (e.g. think of Amazon S3 or G
20. 20.▲
    by blueimp 8y ago

    Thanks a lot! By now I've also updated the project page with - Security-related releases on top of the main page: https://github.com/blueimp/jQuery-File-Upload#%EF%B8%8F-secu... - Security guidelines linked in var
21. 21.▲
    by blueimp 8y ago

    Hehe, thanks! :)
22. 22.▲
    by blueimp 8y ago

    For a breakdown on how this could happen, please see my comment here: https://news.ycombinator.com/item?id=18267309
23. 23.▲
    by blueimp 8y ago

    Larry was also super helpful in identifying the underlying issue and very polite in his emails. Would definitely write another security vulnerability into my code again if I knew that Larry would report it. ;)
24. 24.▲
    by blueimp 8y ago

    Thanks for your comment. I think in situations like this it's important to take responsibility and provide as much transparency as possible.
25. 25.▲
    by blueimp 8y ago

    Agreed - in addition to performance issues, there are also security issues if .htaccess support is enabled - because they can override security settings. Originally the PHP example code didn't have a .htaccess file - I trusted develope
26. 26.▲
    by blueimp 8y ago

    Unfortunately, I never tested it with an Apache configuration that had .htaccess support disabled and so it simply did not occur to me that the default was "off". I think the bigger issue was that the PHP sample code allowed all f
27. 27.▲
    by blueimp 8y ago

    I agree, the sample code should have been secure by default (with all web server configurations) because it's guaranteed that someone will use it as is without checking their own server configuration. And inexperienced webmasters were
28. 28.▲
    by blueimp 8y ago

    Thanks for your comment. I do think that I share at least part of the blame. Enabling all file types by default was not necessary and would have prevented this issue. Especially since there are so many inexperienced developers using PHP, th
29. 29.▲
    by blueimp 8y ago

    Thanks a lot!
30. 30.▲
    by blueimp 8y ago

    Author here - please see my comment here: https://news.ycombinator.com/item?id=18267309