Is there a way to remove the control panel in liferay completely through server-side settings? Because my users don't even want the admin to view the Admin button to access the control panel. Was thinking of removing the my account portlet in the liferay-portal.xml but it is still appearing for the adminstrator.
Simple do not show the docbar on the page. The doc bar can be disabled by removing the following code in portal_normal.vm
<#if is_signed_in>
<#liferay.dockbar />
</#if>
Simple "visual" hiding may not be enough because you'll still be able to access the Control Panel through the direct link (/group/control_panel).
So to disable it completely, take a closer look at the following method:
com.liferay.portal.events.ServicePreAction.isViewableGroup() {
....
if (group.isControlPanel()) { }
....
}
If they don't trust their administrator to make sensible use of the permissions that come with an administrator, why not just provide a user account with less permissions - e.g. not being able to access anything in controlpanel. Accessing to CP is a standard permission that you can grant or revoke to custom roles.
If you ever want to configure Liferay again, I'd advise to keep CP around.
Related
According to the spec, you can prompt the browser to allow the user to grant or deny browser notifications. Once the user has granted permission, is there a way to programmatically deny that permission too?
Calling window.Notification.requestPermission() after they have granted permission does nothing except run the success promise.
My goal is to have an On/Off button toggle in the user settings portion of my site. As far as i can tell, there is no way to toggle off once toggled on.
Unfortunately I don't think this is possible at the moment.
In the future we should hopefully be able to use the Permissions API to check and revoke notifications (as well as other APIs like geolocation etc).
However, while we can currently query the status of a permission, the revoke method is unsupported. I believe it was possible in Firefox until recently, but in 51 the functionality was changed to default to off.
As per MDN:
The revoke() function has been disabled by default starting in Firefox
51, since its design has been brought into question in the Web
Applications Security Working Group. It can be re-enabled by setting
the preference dom.permissions.revoke.enable to true.
Example of permissions API:
navigator.permissions.query({name:'notifications'}).then(function(result) {
console.log(result);
});
Result is prompt/denied/granted. Change 'query' to 'revoke' for denying permissions.
navigator.permissions.revoke({name:'notifications'});
Alternatively, this answer from a couple of years ago suggests an alternate approach which you might find interesting - using localStorage to approximate this functionality.
In liferay 6.2 to Disable Reset New password page from user Login the
following properties were added in portal-ext.properties file.
To turn off password reset page
passwords.default.policy.change.required=false
but still the new user when he logs in for the first time in liferay can view reset password page and user can reset his password.
if anyone knows the solution how to disable password reset page in liferay 6.2 please share the solution. it would be great help.
thanks in advance
Some properties can be changed in portal-ext.properties after first installation, but some of them can't.
Furthermore, if you change some property at the control panel, you won't be able to manage it from properties file anymore, as it goes to the database.
When a property change has no effect, the first thing to look at is who manages it (file or database). You can see it in your control panel:
http://localhost:8080/group/control_panel/manage/-/server/properties/portal-properties
Search for your property and look at the origin icon. It can be a file or a database. If it's a database, you must go to the passwords policy administration to manage it.
You can set properties in portal-ext like users.form.update.main=details,organizations,sites,roles
Restart the server and the problem is solved.
We plan to implement a company-internal portal with Liferay 6.2. Since many of the team members are not within the company's network, the access has to be allowed from the internet.
Now I see a big problem with the Guest role, since it 1) can access Guest-viewable content without login and 2) this is the default selection when for example uploading a document.
What I really need, is that only the login page is generally viewable, but all other sites and content is only visible to logged-in users, without the need to explicitely assign the permissions for each item correctly.
So the question is, can I prevent the guest role to access anything beyond the login page, so to say eliminate it from everything within the portal?
Update:
It was proposed to use only private pages. While this might work, it implies as far as I know, that each user has to be member of the site. But then it's no longer possible to have a site structure with different users participating in different sites and still be able to view public infomation (meaning public for all logged-in users) - or am I wrong?
Update 2:
I agree to a solution where one has to prevent the assignments to the guest role programmatically, via hook or via deeper changes in liferay. Yet, I like to double-check that administrative and think of a periodic database job or program using the API which check for relations to the guest role which came in around the hook or by wrong permission settings of a user and delete them again. How could that be done?
When a document is uploaded through a private page, the permissions actually default to be not accessible to "Guest". This is guaranteed easiest if you don't have any public pages.
Also, you can access the API and change the default permissions once a document gets uploaded (no need to override core Liferay functionality like defaults): Just write a service hook that overrides the upload of a document with a version that sets the permissions you want right after a document has been uploaded. This will catch all other upload attempts, e.g. through services, Webdav etc.
Edit (after your comment): Added the link to Dev Guide. The actual use of the API is a bit too much to update this answer with on the fly. You might want to look at old examples like sevencogs (part 2) to get used to the actual API, but DevGuide will describe how to write the plugin in the first place.
You could still use the public pages etc. and disable the guest's VIEW permission on every element but the login page and it's resources.
Now, as you have already noticed, the fact that, by default, whenever creating any content the Guest gets the VIEW permission is a substantial problem.
I'd suggest to simply override the <guest-defaults> values in Liferay's core portlets' resource permission files (the ones in ROOT/WEB-INF/classes/resource-actions/) to remove these default values. If it's not clear to you on how to do it, see, e.g., this forum topic: https://www.liferay.com/community/forums/-/message_boards/message/486154 .
All you need to do is delete all public pages. Every page that you create should be private. Don't worry about login page, reset password and self-registration (if allowed), by default they are public.
Hope this helps.
There is an application that we are using it both on XPiNC and browsers.
Before you can access the application, you must log-in with your user.id from lotus notes. The problem is there are several login msgboxes ( where you must again log in with your username and passwords ) saying:
The server says /xsp/.ibmxspres/dojoroot-1.8.1/dojo.
or
The server says /xsp/.ibmxspres/.mini/dojo/.en-us.
or
The server says /xsp/.ibmxspres/.mini/css.
or
The server says /xsp/.ibmxspres/.extlib/icons.
and so on. Even when I just hit F5 when I'm logged on in application ( there is, also, a computed field which displays the username ) those type of messages are being displayed.
What should I do as a developer? Or there must be some settings at the server?
I have the following ACL rights:
ACL: User type: Person and Access: Manager.
Effective access: all the checkboxes are checked except Full Access Administrator
Thanks for your time!
Ok, this should be straight out of the box ;-)
What I find strange is that the ressources you seem to be asked for access to use are some of the "built in" ressources (Dojo, css, etc.) in XPages...???
So first thing is really to test that this has nothing to do with your application:
Create a new application
Set a proper ACL that will force you to log in (Default reader or higher, a person called "Anonymous" no access)
Create a simple XPage and open it from the browser
What happens?
If everything works, then you need to add some elements that use the ressources (css, Dojo, etc.). Then what happens?
I guess you will see the same problems... If so, you need to have a look at the way you have set up your server for web access. Are you using internet sites? Do you use basic or session based authentication?
What does the ACL of your application look like?
What you experience could be caused by "realms" i.e. the "path" to which you log in. A simple example:
If you are required to log in to access the ressource /path/db.nsf/view/doc1?openDocument then your realm will be "/path/db.nsf/view/" - if then you try to create a document using /path/db.nsf/newDoc.xsp then you could be asked for access to the realm "/path/db.nsf/".
I must admit that I haven't seen these issues for quite a while - but that may be due to the fact that I control access to the database as a whole - if users need access to something inside the database I implement it using "public access". But first, let us hear a little more about your findings before we chase it as a realm issue ;-)
EDIT:
Ok, so you are using basic authentication. There are lots of good reasons to use session based authentication instead. However, that does not explain your problem. What OS are you using? An OS with file access in the file structure? Could it be that the user running Domino does not have access to the ressources? Have any (file) restrictions to these directories been set up? You really should not be prompted to login for these ressources....
Did you try another "new" application?
/John
Switch to session based authentication. The multiple prompts point to BASIC where you can't logout unless you close the browser
I created 3 users for testing(user test1, test2, test), but when i logged in by user test1 and access test2's public page, i can edit that page ???
how to config to disable ?
Depending on what you mean with "edit the page":
If all users have the "Administrator" role, they will be able to add portlets to the page
It's a public page, so by default everybody can access that page. If there's a Wiki with public write permissions, everybody will be able to edit that Wiki.
If the users are "friends" - either explicitly or implicitly through belonging to the same organization - they can write on each other's wall
As you state in the comments to this answer, just the PowerUser or the User role for a single user seem to be enough for your users: Try to reproduce this on a new installation - e.g. download the version you have (and the latest available) and see if you can reproduce there. It might be that the permissions for these roles are messed up. You can also compare what a User (role) is allowed to do in Control Panel / Roles / [Power]User / Define Permissions - compare your installation with a default install.
Also, you don't state what version you're using. I couldn't reproduce this behaviour.