I'm using the subsites module to make a multi site system.
I'd like the users logins to the sites to be independent. So if a user has registered on one site, they can't just go to another subsite and login - they have to register for that site too.
In other words - registrations on each subsite is completely independent.
Is this possible?
Technically it would be possible to write a DataObjectDecorator for the Member class, and add a SubsiteID to each member, and then add a filter for that SubsiteID with argumentSQL().
And you need to modify the register form to consider the SubsiteID and hook into the authenticator.
But could very well be that there are a couple of other points you need to hook into to get this to work.
So yes, it should be possible, but it is going to take a long time, and it will be a pain in the arse to get it working properly.
you should carefully consider if you really need it that bad that you need to go this way.
It should be possible to just work around this by using groups, and setting group permissions.
I know this is pretty old thread, but in case someone stumble upon this thread, it will be useful.
There is another hack for this.
/mysite/extensions/CustomLeftAndMain.php
<?php
class CustomLeftAndMain extends Extension {
public function onAfterInit() {
self::handleUser();
}
public static function handleUser(){
$currentSubsiteID = Subsite::currentSubsiteID();
$member = Member::currentUser();
$memberBelongsToSubsite = $member->SubsiteID;
if($memberBelongsToSubsite>0 && $currentSubsiteID!=$memberBelongsToSubsite){
Security::logout(false);
Controller::curr()->redirect("/Security/login/?_c=1001");
}
}
}
and in /mysite/_config.php add an extension
LeftAndMain::add_extension('CustomLeftAndMain');
What above code basically does is, the system lets user login no matter which subsite they belong to. And as long as application is initiated, whether the logged in user belongs to current website or not (method handleUser does it.).
If user doesnot belong to current site, then they are logged out and then redirected to login page.
The description says (among other things):
"The subsites module allows multiple websites to run from a single installation of SilverStripe, and share users, content, and assets between them."
"The branches can have separate users/admins, and information that is individual."
If you don't have a common "headquarter", I'm not sure the module is right for you. Instead of hacking the module to do something it isn't intended to do, why not make separate installations?
Related
Every time a user is 15min inactive silverstripe will log out users from the front-end and redirects them to the registration page.
I have not set any of this manualy and i have no glue where this is coming from. So I guess this is implemented by silverstripe itself?
I realy tried hard to find a solution. So maybe some one can help me or point me in the right direction. Where can I change the redirect after logout. This is how i would do it:
$this->redirect('security/login')
Thats all. But i was not able to find out where to put it.
I'm not exactly sure what you mean, but as you can see on Member::logOut() there are some extension hooks you can make use of, a member extension like below could be what you're looking for:
class MyMemberExtension extends DataExtension
{
public function memberLoggedOut()
{
Controller::curr()->redirect('/MyDesiredPage');
}
}
Now, by default Silverstripe won't log people out due to inactivity so that seems like the work of some custom code that has been put in place on your website either by a module or another dev.
We have a Mediawiki installation at our company. The original Wiki admin has left. I don't know who has admin rights or the admin username and password.
I only have user rights on the wiki.
Goal: To change h2 headers, and the .mw-headline class, to have an underline when the page is printed.
I've searched Google and MediaWiki help and found I have to make a link to and edit User:Chuck/Print.css.
On one of my Mediawiki pages I've tried to make a link to [[User:Chuck/Print.css]], edited and saved it, but the changes don't take effect.
I don't know if the variable $wgAllowUserCss = true; is set because I only have Wiki 'user' rights.
What can I do to get the Print.css to work?
Thank you for your help.
There are two meanings of "admin": the one who is given a role administrator in the MediaWiki website, and the one who controls database and the server. I don't know which one were you referring to (it is also possible that both are the same person).
Assuming that $wgAllowUserCss = false;
Then, if you managed to find someone who can access the server, you could ask that person to edit LocalSettings.php so that $wgAllowUserCss = true;, and now your User:Chuck/Print.css will work. Note that it is absolutely impossible to make your User:Chuck/Print.css work while $wgAllowUserCss = false;.
Otherwise, if you managed to find someone who is given a role administrator, and it is okay to make your change to Print.css systemwide, you can ask the administrator to edit MediaWiki:Print.css. This guarantees to work even when $wgAllowUserCss = false;.
Usually there could be more than one user who are given the role administrator. You could see the list of administrators by going to the page Special:ListUsers. For example, here's all administrators in English Wikipedia: https://en.wikipedia.org/w/index.php?title=Special%3AListUsers&username=&group=sysop&limit=50
Please also note that if you can access the database, you can give a role administrator to a user in the website via the database too.
Assuming that $wgAllowUserCss = true;
It is also possible that in fact $wgAllowUserCss = true;, but the change doesn't take effect. Read https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache for the solution.
Note: without an admin (in both meanings), pages cannot be deleted, and a lot of system changes cannot be done. Your company wouldn't be able to stay in this state forever. Perhaps you should ask your company to install a new wiki.
I'm working on a site which is going to be used by different schools my company that is working with. A school will have a specific user account and I want to be able to provide school specific content that will only be visible for the logged in school (pdf:s etc).
I've been looking around but haven't found a straightforward solution for this yet (is there even one?). So, what is the best way of doing this?
First of all you have to create a custom role with certain capabilities with the add_role() function and then show content based on the capabilities the current user has with the function current_user_can() you didn't mention if the content will be in the backend or frontend but the principle is the same.
Edit:
Also this plugin seems to cover what you need link
For a current project i need to provide some of the client's clients (you go it? =) some kind of protected frontend content area. This area should hold protected content on a "per User"-base.
For example: Tom from (lets call the company EXCORP) wants to provide User A with a document (PDF) and some Text (HTML-Content). But(!) User B would get a totally different document and maybe some more Text. User C would possibly not get a document at all.
This Game goes on for circa another 150 users or so. So going by "default" roles doesn't work here, since i would have to create one user-role per user and that would definitely overkill it. And all the Membership Plugins i've found do not work that way.
Just to make that clear: This thing only goes one way. Meaning, Client-Supporter Tom (in example above) needs to provide all the clients some personalised information. Tom would be a Backend-User. Clients do not need to provide eachother some files or information. Just from one Backend-User to all the different Frontend-Users.
So my question clearly spoken: Is there a way to protect frontend content on a "per User"-base using Wordpress? It doesn't matter to me if I get it to work the "hacky" way, or by a premium/free plugin, as long as it is safe (I will use SSL of course). I just don't want to develop a plugin from scratch, though my client would never speak the budget to pay for it!
There are a lot of themes outhere that offer front end user dashboard, you can use one of thoes themes to have everything set up (user redirected to his/hers dashboard at login).
At this point you have many ways to acchive what you need, if it's not too much trobule to remember what user received what info you can simply add a user-box in post-creation/edit backend where Tom can create a post, attach files to it and asign it to another user(throw the user box).
Publishing the post as private and changing the author from Tom to the end-user should make your work much more easier.
P.S. Check classifieds themes to see how backend works the main difference between thoes and what you'll have to achieve is that the post is craeted by Tom but asigned to the user (very easy to do) and that the post MUST BE PRIVATE!!! don't forget this if the data is sensible!
I realize this is an old question, but thought this might help others. You could try using wp-document-revisions along with the members plugin to achieve what you are looking for.
Good luck.
I'm working with ASP.Net MVC and I would like to make a web site accesible via the internet, but only to a select few people right now. I want to do something basically exactly like the beta access page with password just like they did on stackoverflow, serverfault, and superuser.
I don't just want to check and redirect in the home controller, I want it to always go there no matter what url is used.
Anyone know how they do it?
I don't know enough about MVC in particular, but it would probably mean creating a base controller and overriding OnActionExecuting or OnAuthorization.
I'd create a custom filter that extended AuthorizeAttribute. That way you can put it on the controllers/actions you wanted, and remove it easily enough. Since it's essentially a decorator, you would be playing nice with the Open/Closed principle too.
If you override AuthorizeCore you can check session/cookie/whatever for the login and if that passes, run the base AuthorizeCore too.
The easy way is to put something in the users session. Run a check either on the master page or in an http handler to see if this session is correct or not. If not redirect to the password capture page. When the password is provided then set the session variable...wa la they are in.
If you want to remember them then also drop a cookie and add that to your check as well.