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.
Related
Good Morning,
as from the title, i'd like to create a proprietary database to be integrate in a Typo3 website.
I'd like to receive some advise on which is the best solution:
- is it possible to create tables directly from Typo3?
- is it better creating a database, for example with MySQL and then integrate
it?
In the second case, how coud that be done?
are there other options?
I hope this is not an already answered topic, in case, please send me to it ( i could not find so much information.
Thanks in advance.
If I understand your question correctly, you want to add a custom Extension to TYPO3, containing custom tables. From a content side, this is perceived as a "database", right?
TYPO3 has a framework for that called Extbase. You can "kickstart" a TYPO3 extension with the "Extension Builder" https://typo3.org/extensions/repository/view/extension_builder by entering the "Model" (the data structure) via GUI and then you get all tables etc. automatically set up.
After that (aside from general TYPO3 knowledge), there is some coding involved. In theory, it's possible to make a "round trip" back to the extension builder from the code, but I've never done that.
You need to know / learn the specificities of extbase / php, which is is based on some "convention over configuration" rules and has some additional tweaks to plain PHP (functional comments). Here's a great resource: http://www.extbase-book.org/.
With that, you have great flexibility and powerful tooling to build almost anything inside TYPO3.
From a TYPO3 view it is best if you are able to hold your data in the TYPO3 database. You need to create an extension to handle your data. In TYPO3 an extension can define it's own tables and with updates of the extension updates in the datastructure are handled automatically.
Since version 8 there is a new layer (doctrine) and so it is possible to define further databases for individual tables. With some restrictions you are able to even use different database (-systems) for different tables.
Anyway you could program your own database interface to get and store your data independent from any TYPO3 restrictions, but then you need to handle everything on your own.
Using the TYPO3 core API will help you in multiple ways to handle your data without programming everything anew.
Especially if you use extbase (and the EXT:extensionbuilder) you will get a complete BE data handling, FE-Plugins with Fluid templates to present your data, even data management from the FE could be generated for you just by defining the datastructure. Of course versioning, workspace and timed visibility support are also available if you use TYPO3 structures which includes some (mostly invisible) fields aside from uid, hidden, deleted.
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.
i have registered a project at ourproject.org and requested a mysql dp,they answered at my email and said that i can acces relative information at home/users/my_user_name/dp.txt but it just directs me to my use page.
first:how can i access the dp ?
second:i want to install mediawiki on it but they say that i should install it to the web space of the project ,by web space do they mean the ftp server ?
third:i want to enable interwiki's(eg: en.wiki , es.wiki, ...etc) should this be configured during or after the installation of media wiki.
On you third (second) question. Interwiki means between wiki's, meaning that it link from one wiki to the other. You can set up your other wiki's after you set up the first one.
Also when your wikis are basically the same, except for the fact that they are in different languages, you should refer to the interwiki links as interlanguage links.
About setting up the MediaWiki. You first need to set up a MySQL DB (I assume that is what you mean with dp?). Then you upload the MediaWiki files to your FTP server (it is recommended to do this to the /w folder). After this you can just visit your wiki (at ourproject.org/w) and set it up (including giving it the MySQL DB information).
Is it possible to add an options screen to a Wordpress MU theme (options being saved for each user, so blogwide, not sitewide) ?
I'm used to program wordpress themes, but i'm a bit puzzled as to how make customization happen in a multi-user environment...
Wow, no one answered you after all this time? Okay, here's the answer. If you inspect your MySQL database after you get a few WPMU blogs up and running, you'll notice that each blog has a separate table prefix. The wp_1_ prefix goes to the main admin blog. And then wp_2_ prefix and so on go to all the non-main admin blogs that you create in the wp-admin system. If you want to use the Codex function to access which table prefix, it's actually easy -- just do "global $table_prefix;". In fact, as a side note, WordPress emits a ton of global vars that are quite useful and you can find out what these are by doing "print_r($GLOBALS);die();" in like a plugin or theme file.
But anyway, the answer to your question is that if you look into the MySQL database, you'll find that each blog in WPMU gets its own options table, and it is separate, not sitewide, but blogwide -- just as you desired. And when you use the standard WordPress options API, it will access the options table you need automatically without you having to use the $wpdb global object and without you needing to use $table_prefix global string.
So, if you are using get_option(), update_option(), add_option(), and delete_option() -- these will all work still in a WPMU environment. And even though the plugins folder is shared among all blogs, a plugin's settings are not and are exclusive to each blog.
Now, if you are not using the WP Options API in the Codex, but are going at it with the $wpdb global object, then you'll need to be aware that you'll need to address tables by the $table_prefix global string as part of the table path. There are some cases where this is desirable, such as having a LOT of data that you need to store in a custom table. For instance, storing HTTP_REFERER and user agent info into a table for connections coming in.
Is it possible to set Access persmissions using Active Directory users?
Edit: The overall objective is to allow some users to see certain tables and deny this permission for other users. I'm wondering if it can be done using active directory users.
Depends on what you mean by Access permissions. Access user level security do not interact with Active Directory in any way. ACC: Microsoft Access Security FAQ Available in Download Center It is suggested you reread this FAQ several times. I must admit I never quite understood it. Also see ACC2000: Overview of How to Secure a Microsoft Access Database
Now what you could do is read the Active Directory data for the logged in user and groups and such. Then with some local tables mapping the various AD groups along with the login userid to the various objects and menu items in Access you could control access in this fashion. Note however that local tables can possibly be mucked with by a savvy user, etc, etc.
The most useful URL I found was the following newsgroup posting need help on get list of W2K ad Domain (fqdn) by using VB Options I kept a page of notes when I was working on this topic but they may or may not be useful. I can post them if desired.
I agree with the things that both Tony and Philippe has posted. I just want to add a bit:
If you really need security, then a Jet/ACE back end is not going to do the job for any significant definition of the word "security". Jet ULS is crackable and fairly easily so for anyone with even basic programming chops. Thus, if it's DATA SECURITY that you're looking form, Philippe is right that you should choose a different database engine.
But if you are only looking to control ACCESS in your front-end application, you have three choices:
maintain a couple of tables in your database of your users and the permissions on each of the objects.
implement Jet user-level security.
use AD users/groups in place of Jet ULS.
None of these choices is seamless.
And all of them mean that your front-end has to be programmed to deal with the issues.
If you're restricting access for security reasons, then it makes sense to use a database engine that integrates with Windows security (i.e., SQL Server).
If you're doing it just to streamline program flow, and to adapt the app at runtime to the needs of particular users, then you don't necessarily need security on the data store so much as you need a way to keep track of who is using the database and what groups they belong to, and then what parts of the app they should have access to (and, secondarily, what level of access, read/write, read-only, etc.).
I have used Jet ULS for this last purpose for years, but have never been entirely happy with it because it's not that easy to make it user-manageable. Integration with AD would be a good choice, but that means that whoever administers your app needs to have the permission to manage AD users. This may not be something your friendly neighborhood sysadmin is willing to agree to.
On the other hand, if you end up needing both back-end security and front-end access control, you can't beat a SQL Server back end using Windows security for one-stop shopping via AD.
According to the few questions you posted these last days on Access, it seems obvious to me that you should consider switching your tables (not your forms) from an Access/mdb file to a SQLExpress server, where all these security issues can be easily managed. Upsize your database, add your connection string as a public variable in your client app (or in an xml file, local table, or anything else that can hold the string, even an extra property of your access file can do the trick through the currentDb.createProperty method), and go for a real client-server configuration.