With Liferay 6, using *LocalServiceUtil static calls was common. Starting from Liferay 7, these calls should be avoided in favor of #Referenceing the OSGi service and using it as a private member of the class, if I understood correctly (feel free to correct me).
Problem: When I replace my old *LocalServiceUtil calls with the OSGi-friendly equivalent, I get this exception:
com.liferay.portal.kernel.security.auth.PrincipalException:
PermissionChecker not initialized
at com.liferay.portal.kernel.service.BaseServiceImpl.getPermissionChecker
at com.liferay.portal.service.impl.UserServiceImpl.getUserById
How to fix it?
I could get a random admin via the OSGi equivalent of UserLocalServiceUtil.getRoleUsers(RoleLocalServiceUtil.getRole(company.getCompanyId(),"Administrator").getRoleId()) and use it in the the OSGi equivalent of PermissionThreadLocal.setPermissionChecker(PermissionCheckerFactoryUtil.create(randomAdmin)) but that sounds very hacky, plus it would put the responsibility of my code's actions on the shoulders of this unlucky admin.
My code:
protected void myMethod() {
userService.getUserById(userId);
}
#Reference(unbind = "-")
protected com.liferay.portal.kernel.service.UserService userService;
I think you actually wanted to inject UserLocalService.
In OSGi you should only strip the *Util suffix to receive equivalent functionality.
What you did is moved from LocalService (UserLocalServiceUtil) to remote service (UserService). The local services do not check permissions so there is no permission checker initialisation.
Apart from the above, you should be sure that no mischief can happen when using Local services. It's not recommended to expose this kind of functionality to end users but it's fine for some background processing.
Related
I wonder if it is possible to create a new Authority in Jhispter. I tried adding a ROLE_WRITER:
/project/src/main/java/location/security/AuthoritiesConstants.java
package location.security;
/**
* Constants for Spring Security authorities.
*/
public final class AuthoritiesConstants {
public static final String ADMIN = "ROLE_ADMIN";
public static final String USER = "ROLE_USER";
public static final String WRITER = "ROLE_WRITER";
public static final String ANONYMOUS = "ROLE_ANONYMOUS";
private AuthoritiesConstants() {
}
}
When I run the app, it does not crash, but when I tried to change the localhost:9000/#/user-management ROLE in the profile, it did not offer me the option.
So I went to the database and add a new ROLE in the JHI_AUTHORITY Table and now it appears in the user-management, but I have the feeling that i'm getting into trouble if I mess around with the User Entity.
Is there any official way of doing it? (that I am not aware of)
Is there any danger with doing it?
Is there anything else that I should consider?
Thanks
Is there any official way of doing it? (that I am not aware of)
Have you seen src/main/resources/liquibase/authorities.csv? I think that is a right place to add a new authority before production, and when you are in production stage, then it is recommended to add your change(insert into) as liquibase changeset.
Is there any danger with doing it?
AFAIK new role will work like other existing roles in Spring security context. having said that I might misunderstood your question.
Is there anything else that I should consider?
Automation, this type of manual changes will cause dysfunction in production or new installation, so we need to automate this type of changes for both situations.
Although this is already answered, I think it's a good idea to put a link to a related tip posted in the official website of JHipster:
https://www.jhipster.tech/tips/025_tip_create_new_authority.html
I faced the same issue, I added drop-first: true parameter to src/main/resources/config/application-dev.yml:
....
liquibase:
contexts: dev
drop-first: true
....
It seems like it ais a parameter to regenerate the database (for development mode).
I have created a Liferay 7 module, and it works well.
Problem: In the Java source code I hard-coded something that administrators need to modify.
Question: What is the Liferay way to externalize settings? I don't mind if the server has to be restarted, but of course the ability to modify settings on a live running server (via Gogo Shell?) could be cool provided that these settings then survive server restarts.
More specifically, I have a module for which I would like to be able to configure an API key that looks like "3g9828hf928rf98" and another module for which I would like to configure a list of allowed structures that looks like "BASIC-WEB-CONTENT","EVENTS","INVENTORY".
Liferay is utilizing the standard OSGi configuration. It's quite a task documenting it here, but it's well laid out in the documentation.
In short:
#Meta.OCD(id = "com.foo.bar.MyAppConfiguration")
public interface MyAppConfiguration {
#Meta.AD(
deflt = "blue",
required = false
)
public String favoriteColor();
#Meta.AD(
deflt = "red|green|blue",
required = false
)
public String[] validLanguages();
#Meta.AD(required = false)
public int itemsPerPage();
}
OCD stands for ObjectClassDefinition. It ties this configuration class/object to the configurable object through the id/pid.
AD is for AttributeDefinition and provides some hints for the configuration interface, which is auto-generated with the help of this meta type.
And when you don't like the appearance of the autogenerated UI, you "only" have to add localization keys for the labels that you see on screen (standard Liferay translation).
You'll find a lot more details on OSGi configuration for example on enroute, though the examples I found are always a bit more complex than just going after the configuration.
I have an MVC5 project that is doing OwinStartup, and I'm using Ninject.MVC5, Ninject.Web.Common.OwinHost, etc.
I have NinjectWebCommon bootstrapping DI and things were working just fine. Until I started playing with the identity code.
I need to issue a password reset token, which requires a DataProtectionProvider. No problem, the ApplicationUserManager wires that up in the Create method, which is bound to the OwinContext during startup in Startup.Auth.cs:
public void ConfigureAuth(IAppBuilder app)
{
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
...
}
In my NinjectWebCommon I have the following registrations:
kernel.Bind<IDataContext>()
.ToMethod(ctx => HttpContext.Current.GetOwinContext().Get<ApplicationDbContext>())
.InRequestScope();
kernel.Bind<IApplicationUserManager>()
.ToMethod(ctx => HttpContext.Current.GetOwinContext().GetUserManager<ApplicationUserManager>())
.InRequestScope();
The problem I'm having is that the token isn't being issued. Why isn't that what my question is about? Well, if I get an instance of the ApplicationUserManager using the Create myself and use that, things work flawlessly.
Next on my plate a reported user creation bug. Hyphens aren't working in usernames. In that same ApplicationUserManager.Create method, is the UserValidator code that's overriding the default AllowOnlyAlphanumericUserNames value.
Again, if I use a self created dependency, it works as expected. This seems to indicate Ninject's injected dependency isn't using the ApplicationUserManager.Create'd version.
I'm guessing this has to do with the call to: HttpContext.Current.GetOwinContext??
Is there something I need to do in order to inject something that relies on the owin context or something else I need to do while registering my resolver?
I've seen other questions here showing UseNinjectMiddleware and UseNinjectWebApi. I tried that approach, but didn't have any luck, nothing was being injected in...
Any assistance is greatly appreciated!
i am adding a new method into CalEventLocalServiceImpl using hook...
my code is ..
public class MyCalendarLocalServiceImpl extends CalEventLocalServiceWrapper {
public MyCalendarLocalServiceImpl(CalEventLocalService calEventLocalService) {
super(calEventLocalService);
// TODO Auto-generated constructor stub
}
public List getUserData(long userId) throws SystemException{
DynamicQuery query=DynamicQueryFactoryUtil.forClass(CalEvent.class)
.add(PropertyFactoryUtil.forName("userId").eq(userId));
List deatils=CalEventLocalServiceUtil.dynamicQuery(query);
return deatils;
}
}
liferay-hook.xml:
<service>
<service-type>
com.liferay.portlet.calendar.service.CalEventLocalService
</service-type>
<service-impl>
com.liferay.portlet.calendar.service.impl.MyCalendarLocalServiceImpl
</service-impl>
</service>
my question is how to use getUserData from jsp file.
Can anybody help me out....
i think u didn't gt my question...i want list of events based on USERID from Calendar ...to achieve this task what i need to do??
I assume getUserData() is not overridden but a new method (can't look up currently). This is not what you can do when overriding a service. Instead you'd have to add a new Service and make it available to the portal.
Remember that a customized ("hooked") jsp is running in the portal classloader, while your overloaded service is running in the hook's classloader. Thus, if you create a new service and make the service.jar available to Liferay (e.g. on the global classpath) you can call it from JSPs. The interface of Liferay services can not be extended through an overloaded service.
In case getUserData() is already in the interface (as I said I can't look up currently), you just need to call the CalendarLocalServiceUtil from your jsp and it will be delegated to your wrapper.
Just to add to Olaf's answer and comments...
if you you want to extend CalEventLocalService service with just "getUsetData" and use it in one jsp than building your own service might be overkill. Simply put your code from "getUserData" in jsp. Otherwise follow Olaf's suggestions.
In a previous thread one of the respondents said that using wsHttpBinding used a session. Since I'm working in a clustered IIS environment, should I disable this? As far as I know, sessions don't work in a cluster.
If I need to disable this, how do I go about it?
That probably was me :-) By default, your service and the binding used will determine if a session comes into play or not.
If you don't do anything, and use wsHttpBinding, you'll have a session. If you want to avoid that, you should:
switch to another protocol/binding where appropriate
decorate your service contracts with a SessionMode attribute
If you want to stop a service from ever using a session, you can do so like this:
[ServiceContract(Namespace="....", SessionMode=SessionMode.NotAllowed)]
interface IYourSession
{
....
}
and you can decorate your service class with the appropriate instance context mode attributes:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
class YourService : IYourService
{
....
}
With this, you should be pretty much on the safe side and not get any sessions whatsoever.
Marc