I would like to know if there is a way to automate the process of saving a spreadsheet into an HTML file.
I have an OpenOffice spreadsheet that is located at a public file server inside my company´s LAN. A group of people work by editing and entering data into that spreadsheet, but others should only have read access. Since permissions policies can get a little bit complicated with OpenOffice, I thought it might be convenient for those who should only read the data to open the file in their web browsers by entering the route to the file or via a shortcut (specially since a lot of the read-only users are spreadsheet illiterates).
How can I achieve for this an HTML file to be updated every time the spreadsheet is saved by editing users, so read-only users can have the latest version?
Ideally, use a document management system that will keep older versions of the file to prevent mistaken edits by multiple people. Most DMS's provide some users with the ability to edit and others with the ability to read the document.
However, I once worked on a project where we used a large commercial DMS that was too complex for the read-only users. So we also ran a web server that provided read-only access to the documents.
Running a web server such as Apache HTTP Server, it is possible to do what you are asking even without a DMS. Provide a web form for people to submit edits to the document. When an edited document is submitted:
Save a copy of the old file.
Update the main version to the new file.
Run a command line job to convert the document to HTML.
Then read only users can view the HTML file by browsing to the web server.
Without a DMS or a web server, the best that can be done is to set file system permissions, as #mb21 said. That would certainly be easier to set up, and might be good enough depending on your needs.
Related
I am saving data as part of a game, using a CSV file, and want to set it to read-only so that the user cannot modify it (system designed for not very experienced users).
Is there any way to save these files so that they are read-only?
Unfortunately it seems that godot's File API does not provide a mechanism to change file permissions. You could try using an encrypted file, which will prevent the user from trivially viewing it as a CSV file (e.g. it shouldn't open by default in their spreadsheet program). However, an encrypted file can still be overwritten and corrupted, and this will hinder modding for players that enjoy digging around game files.
You could write a proposal to include permissions functionality in the File API, or write the saving code in a language other than GDScript, where you'd have access to a standard library with this functionality. You could write a GDNative extension that supports this.
Ultimately you have to decide how important it is to fool-proof your system. A determined user will find ways to break things.
I was using an Access file a colleague of mine created. They run it without issue on their computer all the time, but when I tried running it on mine, without modifying it, I had a value prompt window come up that isn't supposed to.
I think there's some sort of auto save feature on this file because even after closing it without saving, this message shows up and I'm no longer able to run the macro within the Access file. This file is stored on a shared network drive and file history isn't enabled on this drive nor on my machine. I'm not too familiar with Access and my colleague is on leave for some time. No one else seems to know Access very well either. Is there a way than I can restore the file or the queries/macro inside it to how they were before I opened it?
The basic answer is No. If something really was changed, there is no automatic history that can be used to recover changed settings or macros.
I realize it doesn't help to say anything now, but I am very surprised if there are no backups for the shared network drive. Is there no IT personnel that can assist? Regardless of whether or not you can get the file working, I would immediately make your own manual backup of the Access database file(s). (As long as you have a backup... or even better multiple backups, Access files can simply be restored from the original using file copy and paste.)
"Autosave" is an understatement with Access, because unlike a word processing document or spreadsheet which can be held completely in memory, a database file is constantly updated. There is no in-memory context for the database file as a whole. Access will almost immediately update the file once it is opened, simply because it manages things like file locks, etc. The database may have an Autoexecute macro or other code that runs automatically, but this may be accompanied by security prompts, especially if you haven't opened it on that computer before. For standard forms, changes to data on a form are saved to disk immediately and no "Save" button is required. Certain aspects of the database file should not changed unless explicitly told to do so, and these are usually design aspects not change accidentally.
In one of my Stack Overflow questions about MS Access front-ends, an SO community member suggests that each user should have their own copy of the .MDB or .ACCDB front-end file:
Don't put the database on a network drive and share it with users.
Give each user their own copy.
Is this necessary? What are the problems associated with multiple users accessing the same file?
The estimated number of users for my future front-end is currently 5, possibly growing to 10-20.
It is not necessary if you mark the file itself as read-only (right-click, properties, bottom-left mark) as all temp data then will be forced to real temp files and the file, per definition, cannot be corrupted.
However, the user will be warned about this with a yellow banner when he/she opens the file.
If they can't live with that, you can create a shortcut to copy and launch the frontend which will provide "automatic" updates of all users' frontends at relaunch.
A script that performs this (you may reduce it somewhat for your scenario) can be found here:
Deploy and update a Microsoft Access application in a Citrix environment
I am using SQL Server 2008.
I have a table (TBL_FILE) that stores user uploaded files in binary column. However users do not want to open our system to access the file. They want to have a folder (network drive, Web folder, local drive, local folder... are accepted) that maps to the table (TBL_FILE). So they can directly open the file directly in File Explorer.
The key point is they want to open files directly in File Explorer.
Is it possible to do that? And what kind of program I need to write to do that? And how to do security?
Thanks!
Alex
Have you considered writing an application that would prompt for a login, then present a list of files to the user in a friendly user interface? You could drop a shortcut to that application in the folder they want these files to live in.
If you must have shortcuts directly from the filesystem into your binary data fields, then you are going to have to be a little bit hacky. Depending on how often the files are updated, you can try one of these options:
1 - Write an application that will run as a Windows Service or as a scheduled job. Periodically check for changed binary data, and save it to disk. Disadvantage: the file system will only be updated at intervals, so database changes will not be immediately available.
2 - Write a trigger on the table that saves the binary file to disk. Fire the trigger whenever the row changes- preferably by monitoring a 'last modified time' or similar field, rather than checking the binary value directly. The trigger could fire a CLR stored procedure, or you can do it directly from T-SQL using the method described here.
Disadvantage: You have a potentially time-consuming trigger on the table.
In either case, security becomes the problem of the Windows filesystem. Just grant access to the folder to whomever should see the files.
Good luck!
after searching in google, I finally find a solution of this problem.
We could create a logical drive with .NET technology or other third party libraries. One of the libraries is Doken http://dokan-dev.net/en/.
Doken is able to let us to create a drive in computer and do the logic ourselves. It seems that it is able to map a folder to a table in Database. But I haven't tried it yet.
Thanks!
Alex
My website has been compromised. Some one have injected some iframe markup in my website.
How they have done this? Only on my index.html, index.php page. But I have blocked write permissions for this page, then how they able to write in my pages.
Will it effect other pages on my server?
Is there any other solutions to block this?
Thank you
<?php`
include_once("commonfiles/user_functions.php");
include_once("user_redirect.php");
include_once("designs/index.html");
?>
<iframe src='url' width='1' height='1' style='visibility: hidden;'></iframe>
This is my index.php code <iframe> is injected after the php script.
Someone with FTP access to your site (you or your developers) has a virus on their workstations. This virus has installed a keylogger that is stealing credentials from your FTP client and sending this information back to the hacker.
The hacker collects hundreds of such credentials and then uses a program to log into each server, download a file, modify it to append an iframe or block of obfuscated JavaScript or PHP, upload the file, download the next file, modify, upload, next, etc. The files downloaded may either match a set of names (such as only index., default., home.* etc) or just any html or PHP file.
The appended code is often either an iframe that is visibility: hidden or of 1x1px size, a <script> sourcing a remote JavaScript file on a dubious domain, a collection of Javascript obfuscated by some clever str.CharCode'ing, or a block of base64_encode'd eval()'d code. Unobfuscating the code, the result is often an iframe. More recently, some clever attackers are inserting remote shells, granting them backdoor access to your server.
Once all the files have been modified, the attacker logs out. Visitors to your site will be subject to malicious code from the domain linked in the iframe with the intention of installing viruses and rootkits. Among other functions, these viruses will install a keylogger to sniff FTP credentials... and the virus continues spreading.
The attacker is using your credentials, so they can only access files that you have access to. Sometimes, they will upload an additional file in certain directories with an encoded shell, allowing them return access to the server (the common ones are _captcha.php in /forums directores and img.php or gifimg.php in /gallery directories). If you host other domains on your server, as long as the user for the affected domain has no access beyond their current domain, others will not be affected.
There are two ways to stop this sort of attack -- prevention and proper antivirus. The attacks can be easily deflected by use of a firewall and limiting FTP access to only a few select IPs. The attackers are not attacking from your own workstation (yet), but rather a server elsewhere in the world. Using proper antivirus on all workstations with access to your FTP account -- or, better yet, not using Windows XP -- will help prevent the original infection from occurring.
If you are infected, it's fairly easy to clean the messes up using a bit of clever sed, depending how good you are at spotting the injection and making effective regexes. Otherwise, backups backups backups -- always have backups! ...Oh, and change your FTP password or they'll be back tomorrow.
If the php file itself has been edited to include this iframe and if there truly is no way for another script you are running to write to the file then a user account with access to the file might have been compromised. If there is a user account with access to the file that has a weak password this would be my candidate as the most likely culprit.
They may have used some form of injection on your site to acquire usernames and password hashes and bruteforced those, they might have installed a keylogger on someone's machine who has access, or they may have just brute forced your login directly (assuming you don't have some sort of mechanism in place to prevent this).
First thing I would do is ensure there are no viruses running on anyone's computer who has access to the machine. Then go about changing passwords. And finally review the php scripts of the site for possible points of injection. Trouble spots are pretty much anywhere you're taking in some kind of user input and processing it without first checking to make sure it is safe to process (i.e. failure to strip dangerous characters from a user login form).
From the comments that have been posted so far it seems almost certain that someone has gained access to a user account with write permissions on the files that are having code injected into them. It sounds like some individual has discovered one or more account passwords and has made it their pastime to occasionally log into your FTP and make some changes. Have you tried changing your passwords? I recommend using a fairly secure password, of at least 15 characters and using a variety of character types including unprintable characters if you are able (use alt/meta keys to enter UTF codepoints on the number pad).
If, after changing your password, you still observe the same problems, then there could be another issue. I would first seriously scrutinize your PHP scripts. Anywhere your scripts accept user input from a form, data stored in a cookie, or other data originating from outside the script itself (and therefore potentially "dirty" data), go over the operations of the script with this data very carefully. If you are using any such potentially dirty data to run an OS command, open/read/write a file, or query a database, then it is possible that the data contain escape characters that will escape your code, allowing an attacker to execute any code they wish within your script.
Keep an eye on your access logs. You mentioned that you remove the injected iframe code from your scripts and it keeps being re-injected, so if you can catch when it happens you can probably find a clue as to the source of the changes in your access logs.
See this thread for more on trying to block iframes.