Is Shopware 6 Uploaded Media Stored In The Database? - shopware

Where exactly are the (product) image files stored? I can't find the images in my Shopware 6 installation folders. If it is in the database, explain how it is done and which table because I have looked at the media table and can't seem to decode where the image file is.

As #zabus wrote, this is dependent on the CDN strategy.
Those strategies are implemented in https://github.com/shopware/platform/tree/trunk/src/Core/Content/Media/Pathname/PathnameStrategy, in case you want to know in detail how a path is generated, which happens on-the-fly.
There is a WIP pull request to store the final path in the database.

Public files are saved in public/media, while private files are in files/media.
the env variable SHOPWARE_CDN_STRATEGY_DEFAULT defines how the files are saved.
For example:
SHOPWARE_CDN_STRATEGY_DEFAULT=id

Related

Kentico 10 : How to find the file uploaded by DirectUploadControl

We are using Kentico 10
Question 1
We are using DirectUploadControl to upload image in a page form.
We have column PDFImage in the page type. I can see the value of this field to be a GUID.
Where the image is stored on disk when uploaded by this control? Which table is updated with file name?
I tried the page type table, cms document and media file but couldn't find.
Question 2
We need to process the image when uploaded. Is there an event? Right now we are doing this in DocumentEvents.SaveVersion.After
This depends on how the system is set to store files. So, it can be in the DB or on disk or both. When on disk, it depends what folder is set to store the attachments.
In the document events there is the SaveAttachment event - so maybe you can try using that one. Or, it might be better to create a custom uploader form control - depending on your needs.

Shared Documentation in GitLab over several repos

We have serveral microservices for which we have artifacts in GitLab. (like for example helm chart, valuesfiles...)
For better documentation we have a deployment.png that shows the deployment path. Like where we get the images from and how we import our helm-charts and how to access the Openshift-Cluster from the jumphost.
This diagram should be included in every microservice repo so that everybody who has to deal with the microservices sees the diagram.
Now I don't want to have duplicated code and don't want to check in and take care for the deployment.png and the Text below it in every microservice.
Is there a good solution for that usecase?
We thought about having an extra documentation-repo and pulling in the relevant Readme with the image as a link into the respective microservice-readmes in each microservice-repo...
Any idea or best practice?
If I'm understanding correctly, you want to have a way to reference the same image and text files for multiple documents. All you have to know is the url location to your image and it can be referenced/embedded.
For example, ![deployment img](gitlab.com/.../...)
A statement such as this will embed a file or image in a markdown file. If we remove the ! from the front, it simply links to the file location as a hyperlink.
The same strategy goes for the text file.

Why do Domino store all my inline images in the xsppers folder?

Every time I reload my webpage new files are added to the c:\windows\temp\notes...\xsppers folder on the server. and these files are never deleted, I have to manually delete them, and it can be several GB of data to delete every month
I have a simple xpage with a repeat control that display data from several documents using a computed Field mapped to a rich text field.
the richtext fields contain a lot of inline images that has been added using the notes client.
Now, every time I reload my webpage these images are now detached to the xspper folder and is causing my harddrive to run out of disc space all the time.
What is the reason for this behaviour and how can I avoid it from happening?
In the image below you see all the gifs that has been created with a new uinque name, each time I reload my webpage a new set up images are added to the folder.
I am using Domino 9
As Egor Margineanu wrote, this can happen if your images are not stored as MIME images in your Rich Text item.
This forces the domino server to detach the attachment(s) over and over again to disc, because it is required to generate a GIF form the inline image. If you change the MIME type of your rich text item in your form and save the document(s) again, the images are stored in the "correct" format, and the domino server is able to identify that the images are already on the HDD.
As far I can see the temorarly detached attachments are not wiped when the session ends. This seems to happen if the application ends.
Not a complete answer but some clarification from the XPages Portable Command Guide, page 36:
The files remain in the temporary persistence location until the user
session expires. The file is not removed after the document is saved,
although it is no longer referenced by URLs.
It may be useful to change this
setting to point to a different location if the folder is taking up
too much space on the main server drive and another drive has more
available space. This option is server-wide, so it should be set in
the server xsp.properties file. Values set in a particular
application’s xsp.properties file are ignored.
Based on your question, Thomas, it seems that this is not what you are experiencing.

Question of UIWebView and Core Data

I want to develop a news App such as Engadge etc. The news had loaded from the server, and now I'll save the news included body text and pictures into database(Core Data). Can UIWebView read the datas from Core Data directly, and shows in UIWebview?
Thanks.
Yes and no. You can store the HTML content in the database (CoreData), to show an article you use: loadHTMLString:baseURL: of UIWebView to show the textual content. The images however is probably best stored outside the database as file because you will have to point the image references in your HTML to an actual file.
You could store the images as BLOBs but then you need to pull those blobs and write as files later for UIWebView to be able to pick them up.
I think the easiest way is to store images as files and but place references to them inside CoreData. That way you can also delete them accordingly later on.
If by directly, you mean without any glue code, then no, not on iOS as of present.
You could however use Core data to store text and image objects as desired. It might not be the best idea to use a UIWebView, but to answer your question, it's definitely possible, and in fact quite easy to do so.

What security issues we acquire if we publish a form that lets you upload any type of file into our database?

I am trying to assess our security risk if we allow to have a form in our public website that lets the user upload any type of file and get it stored in the database.
I am worried about the following:
Robots uploading information
A huge increment of the size of the database
The form is an resume upload so HR people will be downloading those files in a jpeg or doc or pdf format but actually getting a virus.
You can use captchas for dealing with robots
Set a reasonable file size limit for each upload
You can do multiple checking for your file upload control.
1) Checking the extension of file (.wmv, .exe, .doc). This can be implemented by Regex expression.
2) Actually check the file header or definition type (ex: gif, word, image, etc, xls). Sometimes file extension is not sufficient.
3) Limit the file size. (Ex: 20mb)
4) Never accept the filename provided by the user. Always rename the file to some GUID according to your specifications. This way hacker wont be able to predict the actual name of the file which is stored on the server.
5) Store all the files out of web virtual directory. Preferably store in separate File Server.
6) Also implement the Captcha for File upload.
In general, if you really mean to allow any kind of file to be uploaded, I'd recommend:
A minimal type check using mime magic numbers that the extension of the file corresponds to the given one (though this doesn't solve much if you are not going to limit the kinds of files that can be uploaded).
Better yet, have an antivirus (free clamav for example) check the file after uploading.
On storage, I always prefer to use the filesystem for what it was created: storing files. I would not recommend storing files in the database (suposing a relational database). You can store the metadata of the file on the database and a pointer to the file on the file system.
Generate a unique id for the file and you can use a 2-level directory structure to store the data: E.g: Id=123456 => /path/to/store/12/34/123456.data
Said that, this can vary depending on what you want to store and how do you want to manage it. It's not the same to service a document repository, a image gallery or a simple "shared directory"

Resources