There's a page: /index.php?title=Special:RecentChanges visible to every user authorized/unauthorised, is there a way to make this page inaccessible for anonymous users?
I've read this page already: https://www.mediawiki.org/wiki/Help:Recent_changes, but didn't find required information.
You could use the Lockdown extension to achieve this
https://m.mediawiki.org/wiki/Extension:Lockdown
$wgSpecialPageLockdown['RecentChanges'] = [ 'user' ];
Related
As per the title really, but to give it more specifics:
My web app has multiple users, each has a different set of permissions and this means that certain parts of the app aren't available to them, in most cases this is simple, whole sections are just blocked out and not displayed at all, but in some cases I would like to be able to wrap a certain section of a page in a tag which if the user hasn't permission to see will either hide this section entirely, or show a "you don't have permission to use this bit" partial view.
I am using .NET Core 3.1 and Razor Pages.
So I am thinking something like this:
<html>
<body>
My web page content....
<permission requires="view_invoices">
<h3>Invoices</h3>
.... invoice content....
BUT - if user has not got permission this section is skipped, so is blank, or shows (/Views/Partial/PermissionNotAvailable)
</permission>
</body>
</html>
Edit - for clarity, I want to be able to write my content assuming the user has permission to view it, but if they don't, the fact that it is wrapped in the permissions tag helper will have it removed or replaced by a server-side helper.
If you are using ASP.NET authorization and razor pages you can do something like the following:
#if (User.IsInRole("ViewInvoices")) {
<h3>Invoices</h3>
.... invoice content....
} else {
(/Views/Partial/PermissionNotAvailable)
}
Where ViewInvoices is a role you added to the database and assigned to certain users. If the user does not have this role that section of the page is not returned to the client.
Manual:Interface/Noarticletext
defines the pages that are shown for non existing pages.
But what about MediaWiki:Nocreatetext, MediaWiki:Newarticle and MediaWiki:Newarticletext? Are these messages outdated or do they provide extra functionality?
noarticletext is the text that is shown when viewing a non-existent page.
noarticletext-nopermission is shown instead of the above if the user doesn't have the rights to create the page (it hides the edit link in the message)
nocreatetext is shown to logged out users when they try to edit a non-existent page and don't have permission to do so. For logged in users it will use nocreate-loggedin instead.
newarticle was used on Special:Contributions to mark new pages. No longer in use since 1.16 from what I can see.
newarticletext is shown above the editor when editing a non-existent page (assuming they can edit).
The rights that determine if a user can create a page are edit, createpage and createtalk. The (all) group has all these rights by default. You can view the groups and their rights with Special:ListGroupRights
I'm using attempting to add an "onclick" object to a page in a singlesite (i.e. rather than multisite) WordPress that triggers an event. The code is:
Send a voice message
When attempting to save the code, WordPress strips the onclick object leaving:
Send a voice message
A user on another forum suggested that this restriction should only apply to multisite non-superadmin users. Again, this is a siglesite with only one admin user.
It is understood that WordPress removes "onclick" from HTML to prevent malicious code. Still, does anyone know how to resolve this?
Thanks.
It appears that with current Wordpress (I'm on 4.9.4), TinyMCE does the filtering directly on the editor screen, not when the form is submitted. The allowedtags and allowedposttags don't seem to matter, so the solution above does not solve the problem for me.
The method I have developed uses the tiny_mce_before_init filter to alter the allowed tags within TinyMCE. The trick is to add the extended_valid_elements setting with the updated versions of the elements allowed for a.
First, look in the page http://archive.tinymce.com/wiki.php/Configuration3x:valid_elements to find the current value for a, which right now is
a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur]
And add to the end of that the onclick attribute:
a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur|onclick]
Then use that in the filter function like this:
function allow_button_onclick_mce($settings) {
$settings['extended_valid_elements'] = "a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur|onclick]";
return $settings;
}
add_filter('tiny_mce_before_init', 'allow_button_onclick_mce');
which you install in your functions.php file in Wordpress. You can see it in action by toggling the text and visual view on the edit page. Without the extended list, the onclick goes away. With it, it remains.
You can solve this by changing the anchor tag into button and adding a script. For more info please refer to this link: Wordpress TinyMCE Strips OnClick & OnChange (need jQuery).
By resolving, I'm assuming you mean to allow the onclick attribute. You will want to be careful with this, because modifying the allowed tags does this for all your users.
You can modify the list of allowed tags and attributes, by adding this to your functions.php file:
function allow_onclick_content() {
global $allowedposttags, $allowedtags;
$newattribute = "onclick";
$allowedposttags["a"][$newattribute] = true;
$allowedtags["a"][$newattribute] = true; //unnecessary?
}
add_action( 'init', 'allow_onclick_content' );
I suggest trying it with only $allowedposttags first to see if that works for you. According to this other stackexchange post, you should only need allowedtags if you need it for comments or possibly non-logged-in users, but when I did something similar in the past, I needed both of them to work.
On a side note, if you want a list of all already allowed tags and attributes, look inside your /wp-includes/kses.php file.
I'm trying to restraint editing on the Wiki (using MediaWiki) that I'm creating as an internal project for my company.
We would like to be able to let the page creators specify none or one of the two following options:
Nobody besides the creator of this page can edit the content of this page
Anybody can edit the content of this page, but there must be an approval by the page creator before the changes are visible (whether it'd be by mail, on the wiki directly or something else - does not matter).
If the creator does not specify any of the 2 options, anybody can edit the page, and the changes are immediatly visible (default behaviour).
I've been browsing the net but I did not find an out-of-the-box solution for this. We managed to make some great custom stuff thanks to the edition of the LocalSettings file but not this.
Is there a solution for that functionality?
I don't know of an extension that would make this easy.
What I think you could do would be to take an extension like Flagged Revs or Approved Revs and make it so that instead of using groups as the determiner of approval status, it uses username. This might not be too difficult. Does this make sense?
I had the same problem as you and now i fixed it, here is the solution:
I am using http://www.mediawiki.org/wiki/Extension%3aApproved_Revs for article protection but it didn't fulfil my need it allowed the user to change the currently approved revision of the article and so the change was immediately reflected on the main page so I hacked it a bit, basically you need only one change
go to ApprovedRevs/ApprovedRevs.hooks.php
and find the following code:
static public function setLatestAsApproved( &$article , &$user, $text,
$summary, $flags, $unused1, $unused2, &$flags, $revision,
&$status, $baseRevId ) {
this is a function declaration just after it add the following code:
return false;
and it will work the way you wanted it to be i.e (the change you did will not be reflected until you approve it)
My theme's custom options panel has the following code...
`
/* initialize the site options */
if(get_option('permalink_structure')==""){update_option('permalink_structure', '/%postname%/');}
`
This checks the permalink option setting and since the WP default is "" which triggers the site.com/?p=x handler. This way, if the user has not yet set permalinks from the default, my script does it for them, by setting permalink to post name. Or at least that what I thought...
However, I've had a few folks who have my template tell me that upon first install, they were getting 404 errors on pages.
Apparently, the workaround is to physically navigate to the Permalinks page and just click "Save Changes" (even though when you first hit this page, the Permalink comes up as if it's correctly entered into the "custom" field.
Anyone know why this happens? Is their perhaps another setting in the db that determines the permalink in addition to what happens when update_options() is called as in the above code?
Well, this probably happens because you're updating value in database table (permalink_structure), while .htaccess remains the same, and that's why mod_rewrite isn't loaded and users are getting 404-errors on pages.
I believe WordPress also adds rewriting rules into .htaccess in order to enable permalinks when you're clicking "Save Changes" in admin panel. Let me dig it out and find out what WP is doing exactly.
EDIT.
Ok, here is the code that is doing what you're trying to accomplish:
<?php
if (get_option('permalink_structure') == "")
{
// Including files responsible for .htaccess update
require_once(ABSPATH . 'wp-admin/includes/misc.php');
require_once(ABSPATH . 'wp-admin/includes/file.php');
// Prepare WordPress Rewrite object in case it hasn't been initialized yet
if (empty($wp_rewrite) || !($wp_rewrite instanceof WP_Rewrite))
{
$wp_rewrite = new WP_Rewrite();
}
// Update permalink structure
$permalink_structure = '/%postname%/';
$wp_rewrite->set_permalink_structure($permalink_structure);
// Recreate rewrite rules
$wp_rewrite->flush_rules();
}
wp_rewrite does not appear to have any effect. Users still have to manually click "Save Options" on the permalinks screen.
I suppose I will run firebug on that page during the update to see what's getting set that update_options is apparently missing.
This would appear to be a bug in update_options when the option being updated is permalink_structure.
Anyone disagree?