Background:
I am making a website where I want modular administrative rights for read/write/edit priviledges. My intent is to allow for any number of access level types, and to base it off of folder structure.
As an example, root admins would have read/write/edit for all site pages. Group A may have read/write/edit to all files in the path www.example.com/section1/ (including subfolders), Group B would have read/write/edit to all files in www.example.com/section2/, and so on.
I have considered two options to impliment this: create a MySQL database that would hold:
Group Name (reference name for the access group)
Read (list of folders the group can read separated by comma)
Write (list of folders the group can write new content to separated by comma)
Edit (list of folders the group can change already existing information separated by comma)
The other option I considered is creating a 'GroupAccess.txt' file somewhere and hand-jamming the information into that to reference.
Question: What are the advanatages of each of these systems? Specifically, what do I gain from putting admin access information in a database versus a text file, and vice versa? (i'm looking for information on potential speed issues, ease of maintainability, ease of editing/changing the information that will be stored)
Note: I'm not looking for a 'which is better', I want to know specific advantages so I can make a better informed decision on what's best for me.
The first thing that comes to mind is that the database would be more secure over a text file for the simple reason a text file can be read over the internet as most web servers serve .txt file by default, this would allow for users with restricted access and non-users of the site to see the whole structure of you site and in turn can make you more open to possible attacks on certain areas of your site.
Another benefit of using a database is that you can easily use a join to check is a user has access to some content in the database where as with a file you'll need to read the file get the permissions and the go build the SQL and get the data from the database.
Those are just two of the things that have stuck out from reading your question, hope it helps.
Related
I want to allow file upload(public/per user), but not sure about how to properly do it.
I've read that it is not recommended to use MySQL for this and instead should use file system for files and indexing them in the database. I remember reading some popular(with many votes) Q/A about this in SO, but can't find it(please send a link if you can).
So how should I do it? I should use some inaccessible folder and store files there with an ID as their name and this name(ID of the file) in the table of files with user_id, and when the user request a file, I should check auth and then send the corresponding file to the user?
There's no single answer to this question. It depends how you want your application to work. It could be perfectly fine, for example, to put the files in a directory that is http-accessible, if you don't need to restrict access. Then you don't need to pass the file through any code, you just link directly to it.
There are also legitimate reasons to store a file in the database. For instance, it's automatically included in backups, it is guaranteed to be deleted when you delete the database row, it obeys transaction semantics, and so on.
This has been asked frequently on Stack Overflow. Here are a few links to ones that I have answered.
Should I use MySQL blob field type? (2009)
What is difference between storing data in a blob, vs. storing a pointer to a file? (2012)
Save file as blob in MYSQL database or as file path (2018)
I also cover this in the chapter "Phantom Files" in my book, SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming.
I am new in web developers world. I have created a website (www.formsify.in) on Wordpress all by learning on internet. I know the basics of coding and programming languages, etc. and the interest so I learn quickly. Now my objective is to let users search and download documents (.pdf). The way I dl it now is by uploading the documents in Media and use buttons to navigate to the page which displays documents in a tabular form.
Now, this works if the documents are less in numbers. But I know the number of documents will increase and it will be very difficult for me to deal with uploading them one by one and creating tables all the time. So I thought to create
(1). Database of documents
(2). Uploading interface
(3). User interface
I want suggestions whether I am thinking in the right direction or can there be a better way to accomplish this. And if this is a right way to do
What database shall I use keeping in mind that I the documents to be stored online so the database should be online.
How should I go about creating the uploading interface keeping in mind that I am not a code-geek.
How shall I be going to design the user interface.
I know these are very wide and open questions. Also because stalwarts here will give me a non-commercial, non-biased view. I just need directions. I was able to create a decent website (as per my standards) when I didn't know much the only thing drove me to do that was that I was hellbent. I will be thankful for any suggestions.
Thanks,
.farhan
So, basically, you should have 2 tables:
User
Upload
User hold an ID and whatever information you want to have on the user and the upload table holds a unique ID, a user ID (of the uploader) and a path to the document
This way, you can select the uploads (add filters if needed) and you can construct the tables and views using the database results
The uploading is a simple html form that will send the file to a php script that will upload the file to a folder (rename it as well) and insert the new path in the dB.
The user interface just needs to hold a bit of html, with a form element and an action to a php script to handle the upload.
You can find the upload script on w3schools, just add the mysql insert to the database.
We are planning to use mediawiki as the basis for our products documentation. Access control will be used to grant customers access to content.
We would also like to use mediawiki for some of our internal documentation, stuff that customers should not access.
Is it possible to configure one installation of mediawiki such that one group of users sees certain wiki content and that another group of users sees other wiki content? If so, please point me to the appropriate documentation as I am not even sure what this would be called (thus I am uncertain where to look).
Thank you.
If by one installation you mean one database, it is sort of possible but extremely unwise. See this section of the manual for explanation and Category:Page specific user rights extensions (especially the Lockdown extension) if you decide to try it anyway.
Using the same installation directory (ie. PHP files) but separate databases is fine. The manual page about wiki farms describes a few ways to do it.
If you mean, that you want to restrict the "view" permission for certain pages to a specific group, then the answer is kind of maybe. With the default MediaWiki installation, that is not possible, as MediaWiki is designed to be "open" to all users (as least the view persmission). You can "just" restrict, that a certain group can read or can't read, but this will always mean all pages.
Maybe your problem can be solved by having really two wikis, instead of holding two "sections" in one wiki. For this you would need:
One MediaWiki installation on your file system (unzipping the mediawiki tarball release), e.g. /var/www/html/mediawiki/
Two mysql databases (or you use two database prefixes)
Two different urls (e.g. example.com/wiki1 and example.com/wiki2 or wiki1.example.com and wiki2.example.com)
A bit more complex MediaWiki configuration
Now, you first need to create two virtual hosts in your webserver. Both should point to the installation directory of your mediawiki (/var/www/mediawiki/). In the next step you would need to create a configuration which will be different depending on the wiki requested by the user (depending on what url is used). This is a bit tricky and a mostly undocumented way in MediaWiki, but in fact it's working like this:
You create a wgConf object
You fill this wgConf object with valid wikis (usually you use a unique name, e.g. the dbname)
You let wgConf extract all settings (using the name of the wiki, e.g. the dbname)
This part is more or less documented at the wgConf manual page. The more tricky way is to parse the url correctly and set all the information you need. The Wikimedia foundation uses a script called MultiVersion. This tool does a bit more as just parsing the url to indentify the wiki, but ok. With MultiVersion you would then set the configuration variable wgDBname which you then use to load the wgConf data. For more information, you should ask specific questions and look into the git repository of the Wikimedia foundations configuration. I use a similar approach with just 2 wikis, and a lot smaller MultiVersion (but it's based on the idea of the WMF), so maybe this will help you understand the way to configure wikis, too.
You want, e.g., also make sure, that the wikis are able to create inter-wiki links to link, e.g., a documentation of your public wiki in your internal wiki and vice versa. And you probably want to make sure, that some database tables are shared by one wiki, so your users just need to register once to access both wikis (and set the internal read permission for users to false, so that you have to give access to users ecplicitly). See $wgSharedDB and the manual for shared databases. The configuration of my two wikis uses this feature to share user tables.
Good morning,
I'm doing a project, the customer prefers to use Access 2013 as the all in one package - front end, database etc.
In short the customer will give their users a blank copy of the database, which is taken on site and used to generate data based on calibration of equipment for that site.
The problem is the customer doesn't want anyone being able to copy the access database and use it themselves. So basically when on site he doesn't want the customer or anyone to go "oh that database is hand, give me a copy and I'll use it for myself".
I know I can compile the database but that will only protect the source.
Any suggestions on the best way to limit the use of the database?
It's been a few years and I may be foggy on parts of this, but I know you can get around password protected databases, and can bypass the 'startup' form/code so that you can open the database and view all the objects. You are correct that an MDE will not show the code. But if you have a table of valid serial numbers or MAC Id's, then I would have a module that encrypts the data in that table. Otherwise someone could add their values and still run the program? We also did some devious things like create an install package that would create some hidden file in some existing folder (with a calculated value as content), then if Access didn't find that file & content it would not run.
I'm looking to make a hopefully rather simple document storage system in sql 2008. We have a general idea of the elements we need, some meta data storage, filesteam, etc, but there are a few things we aren't quite sure of.
Specifically, we would like to implement a fake folder structure, as well as some (flexible) permissions. Permissions could be on a group level or by individual users, and should we should be able to specify no access, read, read/write, on either file level or folder level.
I'm not looking for someone to write this schema for me. But what I am hoping for is someone has resources that would cover these topics?
Thanks
~Prescott
I think you should go with the classic route of having a documents table that would hold the docs (If using 2008 or above look at FILESTREAM). The meta tables would then link to that.
Your folder structure could be achieved by having a folder table, the material table could then have a field to show which folder the material is in.
To get the sub folder levels you would just have a parent folder field in your folders table self linking back to the same table. You can then render that up in a treeview control in what ever flavour language you wanted
Have you looked at FILESTREAM Storage in SQL Server 2008?