Impersonation in GateIn Portal
by Marek Posolda
Hi all,
We've been requested several times by our users/customers to add
"impersonation" feature.
It may be useful for portal administrator to have possibility to
temporary login as another user without knowing his password. For
example: User /root/ wants to verify that user /mary/ really doesn't
have permission to see page X or portlet Y on page Z.
I've added specification page here
https://community.jboss.org/wiki/ImpersonationInGateInPortal . Feel free
to provide feedback here or in comments of specification.
Have a nice weekend!
Marek
10 years, 10 months
Fwd: Setup Root password feature improvement
by Hai Nguyen
---------- Forwarded message ----------
From: Hai Nguyen <haint(a)exoplatform.com>
Date: Wed, Dec 11, 2013 at 8:39 AM
Subject: Re: [gatein-dev] Setup Root password feature improvement
To: Marek Posolda <mposolda(a)redhat.com>
On Tue, Dec 10, 2013 at 6:08 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 9.12.2013 11:35, Hai Nguyen wrote:
>
>
>
>> > - The SetupOrganizationDatabaseInitializer was clone of
>> > OrganizationDatabaseInitializer (in core service), that is hard for
>> maintain
>>
>> Yes, I agree that clone was not more elegant way, but there was not
>> possibility to extend OrganizationDatabaseInitializer with a custom class,
>> so clone was the only option to add custom behaviour.
>>
>> I would suggest to give the ability to extend this class and override
>> logic from other localization rather that exo.core module.
>>
>> IMO, the new behaviors are not much to introduce a new custom class.
> Beside, I don't know why we need introduce more "updateUsers" property that
> is not necessary. If you looking for my PR, you will see we don't need
> SetupOrganizationDatabaseInitializer for this feature
>
> Property "updateUsers" is another thing unrelated to Root user password
> setup. It's mentioned in this JIRA
> https://issues.jboss.org/browse/GTNPORTAL-3296 . It would be nice if
> OrganizationDatabaseInitializer from eXo core doesn't have all methods
> private, so we don't need to fork whole class into GateIn if some minor
> change is required. I can create JIRA to eXo core for this and also for
> "updateUsers" support. WDYT?
>
>
+1 :)
11 years
Error response not propagated properly in ws
by Peter Palaga
Hi Nicolas,
I hope you are the best addressee for this question. I am just solving
[1], where:
(1) A NullPointerException is thrown in
TemplateStatisticService.getExecutionCount(TemplateStatisticService.java:120)
(2) The NullPointerException is catched in
RestResource.safeInvoke(MethodInvoker, Map<String, List<String>>) where
Response.serverError() is returned, see [2]. This is probably incorrect,
Response.serverError().build()
or
Response.serverError().entity(e.getMessage()).build()
would probably be better.
(3) But anyway, this return value is not handled properly in
RequestDispatcher.processResponse(...). There, the result is handled
only based on the expected return type, in this case java.lang.Object,
which boils down to the last else, see [3].
Hence, the main question is if this can be fixed in RequestDispatcher.
Could perhaps the Resource type check [4] be applied also on o, like this:
else if (Response.class.isAssignableFrom(returnType) || o instanceof
Response)
Or can you perhaps see other better possibilities to fix this?
Thanks,
Peter
[1] https://issues.jboss.org/browse/GTNPORTAL-3292
[2]
https://github.com/gatein/gatein-portal/blob/master/component/management/...
[3]
https://github.com/exoplatform/ws/blob/master/exo.ws.rest.core/src/main/j...
[4]
https://github.com/exoplatform/ws/blob/master/exo.ws.rest.core/src/main/j...
11 years
GWT Gadget Removal
by Nick Scavelli
I have made a PR to remove the Export/Import GWT gadget
https://github.com/gatein/gatein-portal/pull/711 from GateIn (hooray,
finally !). The gadget has been replaced by the new Site Admin portlet
so no longer needed. I believe I removed all occurences of the gadget in
gatein, however if any extensions include the gwtGadgets as part of
their PortalContainerDefinitionPlugin in conf/configuration.xml, it
should be removed as well. Not sure if the server will still start up if
the dependency is listed but the war is not included. I'll prob take a
look at this tomorrow. Would be nice if the server still started but
logged a warning or something.
- Nick
11 years
Setup Root password feature improvement
by Hai Nguyen
Hi guys,
Currently, the setup root password feature has some disadvantages.
Those are:
- This feature depended directly on portal core and could not
enable/disable feature
- The SetupOrganizationDatabaseInitializer was clone of
OrganizationDatabaseInitializer (in core service), that is hard for maintain
- The implementation of PortalSetupService is not really good because it
used many static methods and hardcode properties
- Potential buggy https://issues.jboss.org/browse/GTNPORTAL-3320
We has collected issues of this feature and created
https://issues.jboss.org/browse/GTNPORTAL-3315 to improve it
Who can review or have idea about that?
Kind regards,
11 years
