Hi,
I have been adding images to the products module, and they upload to the upload folder perfectly.
When I try to view them however in detail view, they do not show up and when I try and view the image directly with the URL I get a 403 forbidden page.
I have experimented loads with permissions so it canāt be that!
Thanks
Hi,
What URL are you using to view the images? If by directly viewing you mean looking at example.com/upload/file then this isnāt possible for security reasons. This is controlled by the ā.htaccessā file (for apache servers anyway) in the root of the SuiteCRM folder.
Looking at the detail view for Products this displays the image via the upload folder, in essence if you have htaccess rules on then you wont see the product image. This is a bug and weāll look into sorting this in a future release. A workaround would be to remove the line:
RedirectMatch 403 (?i)/upload
from .htaccess but I would not reccomend this since it means files in the upload folder will be readable.
Thanks,
Jim
I was also wondering about this and checked .htaccess and saw the command. Any idea on how you guys will go about fixing this?
I am interested in the fix as well.
Would love to be able to see the product image on the page.
Dear Jim,
Without read access to the uploads folder the Products/Quotes/Invoices/etc. modules donāt work correctly since they pull the product images from the upload folder. Your workaround works, however as you already pointed out, this is not optimal from a security perspective. In other web applications this is usually āsolvedā by adding a long random string in front of the uploaded file name, e.g picture1.jpg becomes 132424131314ssdsd1342_picture1.jpg. Itās more a āsecurity by obscurityā approach, but still, guessing filenames becomes impossible.
Kind regards,
Romeo
There are other parts of SuiteCRM that allow file access via an entry point. This means you can restrict access to logged in users or administrators or whatever other restrictions. Changing the product image to use this method is probably the best choice.
HI,
Try using set proper folder permission on upload.
Hope this heplsā¦
Dear Jim,
Thank you for your feedback. Can you let me know where this can be configured?
Many thanks!
Kind regards,
Romeo
Hi Romeo,
This isnāt something that can be configured at the moment. The Product Image code needs to be changed to use the method that I mentioned which will take a bit of development work.
I actually thought there was an issue for this but I canāt find one so have added this as a bug (https://github.com/salesagility/SuiteCRM/issues/164).
Thanks,
Jim
You can limit the access to certain files in /upload using the .htaccess in the /upload folder.
Order Deny,Allow
Deny from all
<Files ~ "(?i)\.(png|jpg|jpeg|bmp)$">
allow from all
</Files>
This allows access to image file types with case insensitive extension. You still need to allow access to the /upload folder in the root .htaccess by removing the line
RedirectMatch 403 /+upload
Cheers
Hi All,
I fix the issue and the images are showing in both Detail View and List view, Please replace the tag code with this and do a quick repair and rebuild and its working fine.
/home/bitnami/htdocs/mygifts/core/include/SugarFields/Fields/Image/ListView.tpl
/home/bitnami/htdocs/mygifts/core/include/SugarFields/Fields/Image/DetailView.tpl
hey sbachala. Tried your fix. Didnāt work for me, still get 403 forbidden error (in console).
Would I have to change .htaccess file also as indicated by nelem to make this work?
So these are my results here: The changes to .htaccess files as indicated by nelem are all thatās needed to make photos show up. While it also works with sbachalaās changes, I donāt see any reason to make those non-update-safe changes, if not necessaryā¦
Question for me: What are the security risks involved in changing the .htaccess settings as described by nelem?
correction: changing .htaccess files only worked on my local installation, not on the webserver. there I got error 500 instead of 403 after applying the .htaccess file changes. Probably due to added restrictions from the apache vhost settings, Iām guessing.
Thanks for the good work. Is this fixed in the latest release? Found the same issue today.