I've created a custom authentication plugin, which allows me to login to Joomla with my own user Table. So at this point, the authentication to the system is working and a user object will be created. All information until logout can be seen with $user = JFactory::getUser();.
My problem is, that after login, my menue won't be shown. It seems, that my template is not loaded. If I manually change the userid to one of the registered users in Joomla (only the id will be changed, no other values of the user object), the template will be loaded and the menue will be shown.
What do I have to do to get this to work? What is missing, or what do I wrong?
Because of the Joomla rights system, Joomla calls getAuthorisedViewLevels() and getGroupsByUser() in libraries/joomla/access/access.phpin and looks up the groups from user_usergroup_map.
Because it is an external user authentication, there is no user_usergroup mapping.
Therfore I built a work around. During the login procedure I added a function to my plugin which sets the user_id in the user_usergroup_map table for temporary using.
In case of logging out, the entry in the user_usergroup_map table will be removed.
Related
I am using Keycloak to secure my application but I am using an extra database too. I am holding my users in both of them. Thus whevener a change is made to a user, the user needs to be updated in both the Keycloak db and my db. Thus whenever the application's main page loads, I update the user (everytime). Because maybe the user was changed from the Keycloak User Account Management service. And I need to put the change in the db.
But I don't want to do this everytime the app loads. I would like to know if there's a way to know Keycloak acocunt page was opened by the user. (So that I can update the users only then) Maybe Keycloak returns a parameter or smt? I don't know.
If anyone can help, I would be grateful.
I spun up a simple AspNetCore (3.1) web application based on a built in template with in-app authentication (following basic tutorials).
I can run my app and when I try to go to a secured page I'm required to log in.
I register and can log in as expected. I can find my user in the AspNetUsers table in the database.
I want to create "temporary" users that can access some functionality before logging in or registering.
This temporary user would be valid for x days, they can save data to the database and can come back to the website and retrieve that data. If they choose to login or register, this data will be either merged to their account, or the temporary account would become permanent.
Should I create a full user in AspNetUsers, or use some separate method to keep this data.
If I save it to AspNetUser with a temporary role, they won't have a username, password or email, and I want them to auto-login when they leave and come back.
Does functionality like this already exist in AspNetCore Identity?
I am developing an inventory management system. I am using AppWithinMinutes (AWM). Only administrator can add, edit and delete. In this system, the user name is entered in the user field. Other fields are entering other information. How can users see only their own children when they log in to xwiki with their own name? And how can not he see the other kids?
You could implement and EventListener in your application so that, whenever an entry in your application is created, an XWikiRights object is added to the page to allow view access only to the user that created it and some admin group (that is allowed to see all the entries of all the users).
Note that it would be recommended to implement your EventListener as a WikiComponent so that it is automatically registered when your XWiki instance is restarted.
Here is the scenario. I have two objects Users (with username/password) and UserInfo with rest of the data related to user. The Users is an old table with thousands of records and UserInfo is fairly new. I want to get as much UserInfo as I can when the user first logs in.
I'd like to force user to a custom screen after first login and ask for the UserInfo data. Once I get the "required" data in the new screen, I dont show it till the user voluntarily wants to fill in the data under "Profile".
Since there are multiple entry points to the application, I dont want to update all the controllers to check for this.
Is there a way I can use a Spring Security filter or something which is executed on successful login? I had a look at ApplicationListener<AuthenticationSuccessEvent> but it doesnt solve the problem as if I copy paste the link in the browser, it lets me go ahead to the destination without asking for "extra information".
In a nutshell, I want a check after each login which, if fails, user is not allowed to enter the application. No matter how he tries to get in.
In your Config.groovy, configure Spring Security's defaultTargetUrl and tell it to always redirect there:
grails.plugins.springsecurity.successHandler.alwaysUseDefault = true
grails.plugins.springsecurity.successHandler.defaultTargetUrl = '/userInfo/edit'
In your UserInfoController's edit action, you can check that the required fields are present (userInfo.validate() perhaps?) and if they are, redirect to wherever you like, perhaps '/', otherwise render the edit info view.
You can adopt what #doelleri proposed and enhance the rule by those steps:
run a batch task to assign a temporary ROLE_DISABLED role to each user who does not provide supplemental information yet. If the user already had some roles, save them in some property.
setup your authorization rule as that users with ROLE_DISABLED role only allowed to access /userInfo/edit.
in /userInfo/edit, if the user has a ROLE_DISABLED role, render the information input view, and resume user's role after it successfully updated its information. Otherwise redirect to '/' or the path it requested.
Let’s say I have 2 pages in a sharepoint site. Let’s call them page A and B. We are using windows based authentication mechanism. Let’s say I have 2 already authenticated users X & Y. The page A should be visible to users who have certain attribute set to 1 in active directory. Page B should only be visible to those users that does not have this attribute set to 1. Let’s call this attribute SpecialUser. If SpecialUser is 1 for a given user, user should be able to see page A only and not be page B. If SpecialUser has any other value, user should be able to see page B only and not be page A.
In this case, user X has the attribute SpecialUser set to 1 and user Y does not. So user X should only see page A while user Y should only see page B.
There is no group in active directory that includes only users that have SpecialUser attribute value set to 1. We don’t want to create sharepoint group and add these users manually either.
Given these constraints, how can we achieve this authorization? I am thinking there may be a need for custom coding. If custom coding is required, how do I go about it. If not, what is the solution?
If your Web Application can be setup to use Claims Based Mode instead of Classic Mode, you should be able to achieve this without custom coding, since an Active Directory attribute can be used as a claim when setting permissions on the page.
Otherwise custom coding would be required. You can create a custom web part that you place on the page, which can either redirect the user or call SPUtility.HandleAccessDenied(new UnauthorizedAccessException()) for invalid users. To security trim the pages (make them invisible), you would need similar logic in any menus or web parts that display the pages.
If the Active Directory attribute is part of the SharePoint User Profile, you can use the UserProfile class. Otherwise, you can use System.DirectoryServices.AccountManagement to retrieve the value of the attribute.
I think that the easiest thing to do might be to stick with the active directory side. Sharepoint authentication can be a bit fickle. Off the top of my head I would probably suggest creating an active directory group that's meant to hold a list of these users. Rather than updating it manually you could have a service to run every so often (once a day? once an hour? depends on how long you're willing to have stale authentication) and check the user lists in active directory for this flag. The service would then update the group you're using for authentication.
There might be a way to do this more gracefully within the walls of Sharepoint development, but I've not heard of anything like it.