Usually when Responsive FileManager is opened, the thumbnails it uses are retrieved from the $thumbs_base_path folder (configured in config.php). However, in some cases (usually for very small files) the images are taken directly from their original path. This poses some complications for my project. Is it possible to force it to always use $thumbs_base_path?
Figured it out, it's controlled from dialog.php in the root folder of RFM. Here is the "offending" code:
if($img_width<122 && $img_height<91){
$src_thumb=$current_path.$rfm_subfolder.$subdir.$file;
$show_original=true;
}
if($img_width<45 && $img_height<38){
$mini_src=$current_path.$rfm_subfolder.$subdir.$file;
$show_original_mini=true;
}
Commenting this out completely resolves the problem, but of course it's also possible to play with the settings/directories.
Related
Im struggling with Asset\Image. Is there a way to prevent given image from saving on disc and read from given location instead?
Currently Im creating Image like so
$asset = new Asset\Image();
$asset->setFilename($location);
$asset->setData(file_get_contents($location));
$asset->setParent(Asset::getByPath("/"));
$asset->save();
And obviously it gets saved on in the public/var folder.
Unfortunatelly I cannot afford to do so, because there is like hundreds of GBs of photos.
Is there a way to use location to save and later read image content from saved location?
I think this is not possible by php. You can achive your goal by saving all assets in another location and than replace the public/var folder with a symlink
mkdir /your/asset/storage
cp public/var/assets /your/asset/storage
Danger zone starts here, be sure to have a good backup of all assets
rm -r public/var/assets
ln -s /your/asset/storage public/var/assets
This is only an example and might differ on your system
What was your idea to save disk space? The file takes space anyway, on the disk directly or on the disk managed by Pimcore.
If you have hundreds Gb then check please if those images are Assets or their versions (created on each save).
If they are versions then you have options:
limit versions amount/time (see System Settings -> Assets) or in pimcore/system.yml
pimcore:
assets:
versions:
days: null
steps: 3
disable versioning before to save
Version::disable();
$asset->save();
Version::enable();
And remember that one day you can grow big and need more then 1 fileserver. Pimcore Assets can already manage that, but how will you synchronise assets files?
I'm currently making an electron app that needs to play some 40Mbyte audio file from the file system, maybe it's wrong to do this but I found that the only way to play from anywhere in the file system is to convert the file to a dataurl in the background script and then transfer it using icp, after that I simply do
this.sound = new Audio(dataurl);
this.sound.preload = "metadata"
this.sound.play()
(part of a VueJS component hence the this)
I did a profling inside electron and this is what came out:
Note that actually transferring the 40Mbytes audio file doesn't take that long (around 80ms) what is extremely annoying is the "Second Task" which is probably buffering (I have no idea) which last around 950ms, this is way too long and ideally would need it under <220ms
I've already tried changing the preload option to all available options and while I'm using the native html5 audio right now I've also tried howlerjs with similar results (seemed a bit faster tho).
I would guess that loading the file directly might be faster but even after disabling security measures put by electron to block the file:/// it isn't recognized as a valid URI by XHR
Is there a faster way to load the dataurl since all the data is there it just needs to be converted to a buffer or something like that ?
Note: I can not "pre-buffer" every file in advance since there is about 200 of them it just wouldn't make sense in my opinion.
Update:
I found this post Electron - throws Not allowed to load local resource when using showOpenDialog
don't know how I missed it, so I followed step 1 and I now can load files inside electron with the custom protocol, however, nor Audio nor howlerjs is faster, it's actually slower at around 6secs from click to first sound, is it that it needs to buffer the whole file before playing ?
Update 2:
It appears that the 6sec loading time is only effective on the first instance of audio that is created. I do not know why tho. After that the use of two instances (one playing and one pre-buffering) work just fine, however even loading a file that isn't loaded is instantaneous. Seems weird that it only is the firs one.
OS - Debian Stable
I downloaded fonts from a website (that seemed legitimate to me) and transferred the contents to /usr/share/fonts/directory. There's a .uuid file being generated for every directory with a string like this as its sole content:
f25e9432-c6f1-4bbe-a33c-89289a8d17f1
This file regenerates right after I delete it. Is this a malicious program? Is this indexing by the OS itself or is it something like fc-cache running in the background? What could be the cause of this?
This has nothing to do with the fact that you've downloaded your own fonts. This is simply just fontconfigdoing it's job. It very well could just be the cached data created. Only rather, the binary data is being converted into a uuid string/unique ID.
So, I would say no. I do not believe this to be the cause of anything malicious. Nor are any of these occurrences a result from you downloading fonts from your web browser.
Is this the only SO question about listing drives ??
I'm on Windows, I'm a newbee in addon developement, I (currently) use Firefox Addon SDK with Node.js/jpm, but not Web Extensions (yet), nor the XPCOM/XUL thing. Seems like some are mixing the whole thing..
Correct me if I'm wrong, but as of May 2016, Web Extensions can't parse File System (otherwise I would be very happy to have access to the documentation allowing that too ^^.) And it appears that the Require chrome is now deprecated along with XUL/XPCOM things. As I guess everyone is pushed forward (looks like) to go Web Extensions (that is out of the scope of the subject), there's no way I would go Require chrome as I would have to drop it anyway next year...
So how do we list drives in Firefox Addon SDK without importing the deprecated libraries ?
My answer below, but would like to have a better option if any. The MDN page about is :
either talking about deprecated methods
or just showing you how to manipulate a directory you already know the whereabout.
Here is what I could do with the Addon SDK (or initially jetpack if I'm not mistaken), and yeah, that's a kind of hack because I don't know how to do it in a cleaner way, and I don't want to use Require Chrome.
Minimal version :
// index.js or main.js
// declare the io/file API :
var ioFile = require('sdk/io/file');
// array to make attempts :
let drivesIds = ["c", "d", "e", "f", "g", .... "z" ]; // hack isn't it ? :/
for (let i = 0; i < drivesIds.length; i++) {
let driveName = drivesIds[i] + ":\\";
if (ioFile.exists(driveName)) {
console.log(driveName + " is a drive and is ready !");
}
}
And you're done ! Okay, that was pretty obvious, but I failed to find that code anywhere I searched, or a code that does it better (again, without require('chrome'))
Extended versions can :
put the whole thing in a function getDrives() that returns array of drives objects like { path: "c:\\", hasChildren: true, etc: "etc" }. (check for child directories by combining ioFile.isFile() with ioFile.list() in a for loop that breaks the moment a subdir is encountered.
port the code to another addon module, with exports implementations
even encapsulates io functions and properties as members of a global object in a module (you can monitor filesystem changes like unplugged dir, store filesystem tree in memory, etc.)
All that making your index.js file lighter. Can this be adapted to other OS ? I don't know. The title is misleading while this is the only question about listing drives Addon SDK tagged.
Never ever try to build an entire drive tree, that would bring the computer to a halt, and fail at a point or another because io/file is limited to 250-260 chars in path length on Windows.
Security issues ! That's probably why it's undocumented, why WebExtensions disallows io operations ? But, I use that to inject a nice windows explorer (select a dir to save whatever you want in there, shortcutting save as or download dialogs). That's the only relevant reason why I use Firefox. I would go back to dotNet and reinvent the wheel with again lots of security holes if io is not flexible enough (or missing) in WE, or try Chrome instead (if no deprecated API in the next 10 years). Fact is, the moment you can automate io parsing, there will be security issues, but the moment you disallow that, Addon extensions is not the way to go with filesystem.
I have a Java Web App running on Tomcat on which I'm supposed to exploit Path traversal vulnerability. There is a section (in the App) at which I can upload a .zip file, which gets extracted in the server's /tmp directory. The content of the .zip file is not being checked, so basically I could put anything in it. I tried putting a .jsp file in it and it extracts perfectly. My problem is that I don't know how to reach this file as a "normal" user from browser. I tried entering ../../../tmp/somepage.jsp in the address bar, but Tomcat just strips the ../ and gives me http://localhost:8080/tmp/ resource not available.
Ideal would be if I could somehow encode ../ in the path of somepage.jsp so that it gets extracted in the web riot directory of the Web App. Is this possible? Are there maybe any escape sequences that would translate to ../ after extracting?
Any ideas would be highly appreciated.
Note: This is a school project in a Security course where I'm supposed to locate vulnerabilities and correct them. Not trying to harm anyone...
Sorry about the downvotes. Security is very important, and should be taught.
Do you pass in the file name to be used?
The check that the server does is probably something something like If location starts with "/tmp" then allow it. So what you want to do is pass `/tmp/../home/webapp/"?
Another idea would be to see if you could craft a zip file that would result in the contents being moved up - like if you set "../" in the filename inside the zip, what would happen? You might need to manually modify things if your zip tools don't allow it.
To protect against this kind of vulnerability you are looking for something like this:
String somedirectory = "c:/fixed_directory/";
String file = request.getParameter("file");
if(file.indexOf(".")>-1)
{
//if it contains a ., disallow
out.print("stop trying to hack");
return;
}
else
{
//load specified file and print to screen
loadfile(somedirectory+file+".txt");
///.....
}
If you just were to pass the variable "file" to your loadfile function without checking, then someone could make a link to load any file they want. See https://www.owasp.org/index.php/Path_Traversal