I created a spring-boot web project and uploaded it to server already(centOS7).
currently the img upload to jar file on server is stored inside the static package in jar file
this makes the jar file very large and hard to edit.
can some one give me a idea to store the img somewhere else on server and how to find the position of picture out of jar inside html.
First of all, you have to decide, in which directory you are going to store your files and create it:
mkdir /path/to/your/dir
Then assign a newly created directory to your application user:chown <your user>:<users group> /path/to/your/dir
Then, don't forget to give read/write permissions for the user, under which you run your app - to the already created directory.
chmod 600 /path/to/your/dir - this will allow your app to only read/write to the directory and prevent the execution of files within it (for security reasons).
Then just replace the path you already have - with the new one (to the newly created directory).
Please, be aware that there is a lot of security stuff to consider when you're going to store files on your server.
By the way, please consider reading about different storage options like AWS S3, Google Cloud Storage and Ceph.
Please, take into account - that if you're going to store your files on your server - then you should take care about them (for example: keep eyes on space, make sure you have mirroring across discs and so on so forth). With AWS S3, for example, you don't need to care about all of that stuff and it's very cheap.
Related
Bit of a loose question so if it gets marked down I'll remove it.. but..
I'm using Primefaces/Spring/Hibernate for Java server.
My application knows a load of file names I need to upload. Those files are on my local computer. Is it possible to tell the application the root directory of these files, for it to then setup uploads for each of these files without me needing to browse for each file individually?
I assume this is a browser security issue, i.e. the user needs to explicitly state which file the application is allowed to know about etc?
If not I'll have to do it in a local application but I was hoping there was a way a mass upload could be kicked off from the browser by just setting the local directory of the files.
I decided to use the Primefaces uploader, upload all the files in the directory and let the application sort them out once it has them on the server.
I currently manually delete obsolete folders from a published azure website. I know there is an option in visual studio to Remove additional files at destination. My problem is that I have an Images folder (quite large) that users upload, that will be deleted when I publish with this option checked. My question is, is there a way to use this option with exclusions? Meaning, to delete all files that are not in the local project except "\Images" folder?
You can most likely customize the web deploy usage from VS to do what you want but I don't think I would recommend it since things like that tend to get fragile.
I would suggest changing your architecture to store the images in a blob container, then possibly mapping your blobs to a custom domain (https://azure.microsoft.com/en-us/documentation/articles/storage-custom-domain-name/).
Having your images in blob storage will also prevent any accidental deletion of the Images folder by someone else that doesn't know it shouldn't be touched (or you simply forgetting about it one day).
Using blob storage will also allow you to configure CDN usage if ever find that you needed it.
Another option would be to create a virtual directory on your WebApp configuration and put the Images there - that way your VS deploy/publish wouldn't be modifying that subdirectory. This link may help with that: https://blogs.msdn.microsoft.com/tomholl/2014/09/21/deploying-multiple-virtual-directories-to-a-single-azure-website/
I want to find the correct place to save my user settings for my uwp app. I know there exists:
local: Data that exists on the current device and is backed up in the cloud
roaming: Data that exists on all devices on which the user has installed the app
temporary: Data that could be removed by the system any time the app isn't running
-localcache: Persistent data that
exists only on the current device
I can access the above places with ApplicationData.Current. Which are located somewhere in C:\Users\bla\AppData\Local\Packages\1e7e-94a6-4235-a0c5-9b143f8b_8webbwe
The project also contains a Asset folder, and I can't find a good source which tells me where the folder is located when the app is installed (not in developer mode).
Some developers place there settings into the asset folder. Why? What's the advantage? Is there also a file size limit like for ApplicationData.Current ? When deploying a settings folder into the asset folder will it be available for all user which installed my app? Any background informations regarding the asset folder are appreciated.
Settings files are most appropriate in the ApplicationData folders or ApplicationData.LocalSettings or .RoamingSettings See Store and retrieve settings and other app data
The assets folder is purely a convention. The "assets" name is not special other than to suggest what types of files go in the folder. It is just a useful way to organize the application package to have a place for assets (images, etc.) that are used in the app.
When the app is installed the assets will be in the Package.InstalledLocation directory and can be addressed with an ms-appx:///assets/ URI. Typically this will end up somewhere in \Program Files\WindowsApps\.
Putting a settings file in assets would be a bad idea as the InstalledLocation is read-only and as settings are user data.
There is no hard size limit for files in ApplicationData folders, although if too much data is stored in RoamingFolder then it won't roam. The files will still be available locally.
I've been searching around and can't find any clear answers to this. I need a small amount of data - talking kilobytes, probably not ever reaching megabyte range - available as a file on my Azure instance, outside the web app itself, for a web job to work with. I won't get into why this is necessary, but it is (alternatives have been explored), and the question is now where to put those files. The obvious answer seems to be to connect to the FTP, create a directory, plop them there and work with them there.
I did a quick test and I'm able to create a "downloads" directory within the "data" directory, drop some files in it, and work with them there. It works great for this very small, simple need that I have.
How long will that data stay there? Is that directory purged at any point automatically by the servers? Is that directory part of any backups that are maintained? How "safe" is something I manually put outside the wwwroot folder?
It will never be purged. The only folder that can get purged is the %TEMP% folder. All other folders that you have write access to will be persisted forever.
In my code (which has worker role) I need to specify a path to a directory (third party library requires it). Locally I've included folder into project and just give full path to it. However after deployment of course I need a new path. How do I confirm that whole folder has been deployed and how do I determine a new path to it?
Edit:
I added folder to the role node in visual studio and accessed it like this: Path.Combine(Environment.GetEnvironmentVariable("RoleRoot"), "my_folder");
Will this directory be used for reading and writing? If yes, you should use a LocalStorage resource. https://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-local-storage-resources/ shows how to use this.
If the directory is only for reading (ie. you have binaries or config files there), then you can use the %RoleRoot% environment variable to identify the path where your package was deployed to, then just append whatever folder you refernced in your project (ie. %RoleRoot%\Myfiles).
I'd take a slightly different approach. Place the 3rd party package into Windows Azure blob storage, then during role startup, you can download/extract it and place the files into the available Local storage (giving it whatever permissions the app needs). Then leverage that location from your application via the same local storage configuration entry.
This should help you reduce the size of your deployment package as well as give you the ability to update the 3rd party components without completely redeploying your solution. And by leveraging it on startup, you can guarantee that the files will be there in case the role instance gets torn down and rebuilt.