Unable to unlock a page in AEM even though a admin - permissions

We are using AEM 6.4.8 version.
Tried to lock a page through AEM interface as an admin and that was successfull
Tried to unlock the same page as an admin and it is not working. Unable to unlock the page eventhough I am part of admin group.
This is happening in all our environment across al projects. So seems like a instance wide issue.
Can anyone shed some light whats happening here?
Have read in many threads that admin should be able to unloack in any case. But in this scenario, thats also not working
Any specific permissions or so we need to check ?

As far as I know, an admin account won't cut it. You need the built-in admin account. As per Adobe's help pages.
The original user holding the lock does have permission to unlock the page. However, other users, even if a member of the administrators group, DO NOT have the right to unlock pages that have been locked. Only the "admin" account has this right.
Emphasis mine.

Related

Camunda Authorization of cockpit-application not working

I authorized the group of a user to the cockpit-application. I gave the group full access to the Process Definition and Process Instance authorizations. (so pretty much as described in the documentation)
When I try to log the user in, I see the Welcome screen and in the application overview the option to navigate to the cockpit-application.
However, when I click this, I get the Login screen again.
For a fraction of a second I see the cockpit application, but then it immidiatly redirects to the login page. When I try to log in again, it keeps redirecting me to this login screen.
I configured another group to use the Tasklist application and that is working as expected.
I tried to give the authorization on user-level instead of group-level but the same problems occurs.
(n.b.: I am using the Spring-Camunda-Starter for this application.)
I found the problem, I accidentally removed one of the authorizations the system automatically creates when the user is created. I think I might have removed this, as I thought it was not necessary.
It is in the User Authorizations, every user has an authorization from it's own user to that user. When I added this, it fixed the problem.
I found the solution when another user logged in and had no problems. And the found this to be the only difference between the two accounts.
Hopefully this will help someone in the future!

/users/{userId} is only available for current user?

I use the Clockify API to sync objects to and from our other databases.
I try to update the user image from our LDAP user repo; works fine on my own account, but when I try to update the image for someone else I get a 403.
That leads me to the conclusion that everything under /users is only available for the current user (even if the current user is admin of the workspace). If so, can that be clarified in the documentation?
https://clockify.github.io/clockify_api_docs/#tag-User
Is there a way to update user settings/profile for someone else?
That's right. By design, you can't edit other people's User Settings.
This is because the person in your workspace might have other workspaces (be it their own or someone else's). You're only someone's admin in your particular workspace, and they're free to have other workspaces beside yours.
Looks like you are right, I can't GET users/{userId} except for my own user ID. Attempting to get it for other user IDs, even those users on my team and I'm the owner/admin, gives the 403 Forbidden.
I would recommend reaching out to support#clockify.me, they may be able to fix it - or at least they can be made aware of the issue. I've had success in contacting them and they respond relatively quickly.

Can Yii2 RBAC permissions have multiple rules?

It's my 1st time i'm working with Yii2's RBAC system.
I used http://www.yiiframework.com/doc-2.0/guide-security-authorization.html to get myself familiar with topic.
As i needed some kind of administration for roles / permissions, i installed this extension: https://github.com/mdmsoft/yii2-admin
I'm working on application that let's users submit articles. There are two kind of users, Administrators, and normal Users.
I created 2 roles for that purpose. Admin role and User role.
Users (both admins and users) must have ability to edit articles. Admins should be able to edit any article, while users can edit only their own articles.
For that i created 2 permissions. "Edit" permission and "EditOwn" permission. Than i created "IsOwner" rule and attached it to "EditOwn" permission.
I assigned "Edit" permission to Admin role, and "EditOwn" to User role and everything works great.
Now i'd like to create "lock" status for each article. If Article is locked, user can not edit it even if it's he's own article. Admins should be able to edit it even if it's locked.
For that i created new rule "IsLocked" but i dont know how to add it to "EditOwn" permission. I don't know is it even possible to have 2 rules attached to one permission?
EDIT:
Right now, i have this "dealt with" in way that i have additional permission "EditOwnIsLocked" to which i attached "IsLocked" rule which is than child of "EditOwn", which is child of "Edit".
This works, but it feels dirty and plain and simple wrong.
As it turns out, there is (for now) no way to attach multiple rules to a permission.
You can deal with need of multiple rules in way i do right now, by creating additional permission and attach rule to it and than make child<->parent connection, or you can edit your rule to check for all situations (in my case to check for IsParent and IsLocked).
Those solutions arn't perfect but it's what it is for now. First solution spawns unnecessary permissions, and clutter your permission list (in case you are using yii2-admin or similar extensions), but keeps your rules clean, and second solution keeps your permission list clean but makes you retype same code in multiple rules which is kinda oposit of what OOP stands for.

Why can my application see some user's likes and not others?

As far as permissions are concerned, I'm asking for email only (apart from the basic info).
Now, I can use an application access token to query https://graph.facebook.com/FB-USER-ID/movies and get the list of movies the user likes, but this only works for some users and not others.
You're supposed to have to ask for the user_likes and/or friends_likes permission to be able to see this info. Because I can see it for some users, my first guess was they have that information public, and others don't. But I can't find such a setting on Facebook.
Anyone knows what's going on here?
The settings are in the gear cog on this page http://www.facebook.com/editprofile.php?sk=activities so you can set who can view what.
What you want to do is ask for your user_likes permission so that you can get that access to private profiles too.

All users being logged in as System Account

So I have my little Sharepoint single server farm all setup and everything was running pretty smoothly until I noticed this happening last week:
Every time someone logs in, they get logged in as "System Account" instead of "Domain\User"
I've done some extensive searching on here and Google, but the only solution that I came up with was that it was an App Pool Identity problem
Any suggestions?
**
EDIT:
**
I just wanted to say for the sake of anyone Googling this that here is how I fixed it:
In the Administration Page, navigate your way to Farm Credentials.
From there look at your Farm Account in the drop down menu, and make sure that user is set to a profile with enough privileges. Mine was set to NT\AUTHORITY or SYSTEM\NETWORK (I can't remember which; I've since stopped working with Sharepoint) and I changed it to DOMAIN\USER.
After restarting Sharepoint and IIS everything worked and all the users were logging it with DOMAIN\USER instead of "System Account"
Sounds like you are on the right track. I would first check application pool security account. Is it possible that you selected a domain group that contains all of your users?
Also, after actions that Rich Bennema provide, maybe need to perform issreset to applay changes.