Recent Bloggers

Cody Hoag

Staff
6 Mensagens
25 de Novembro de 2014

Duke H

Staff
2 Mensagens
24 de Novembro de 2014

Olaf Kock

Staff
85 Mensagens
23 de Novembro de 2014

Nicholas Gaskill

Staff
1 Mensagens
21 de Novembro de 2014

James Falkner

Staff
99 Mensagens
20 de Novembro de 2014

Meera Prince

18 Mensagens
20 de Novembro de 2014

Marcus Hjortzén

2 Mensagens
19 de Novembro de 2014

priti parmar

7 Mensagens
19 de Novembro de 2014

Miguel Ángel Pastor Olivar

Staff
20 Mensagens
18 de Novembro de 2014

David Kubitza

1 Mensagens
17 de Novembro de 2014

Liferay verzeichnet starkes Umsatzwachstum in Europa

Company Blogs 8 de Maio de 2012 Por Joseph Shum Staff

 

Liferay verzeichnet starkes Umsatzwachstum in Europa

Der Enterprise Portal Provider eröffnet neuen Standort in Großbritannien, ernennt neuen Director of Operations für Europa und verstärkt seine Präsenz mit Neueinstellungen in Frankreich, Benelux

 

FRANKFURT AM MAIN, Deutschland und LONDON, Großbritannien – 2. Mai 2012 – Liferay Inc., der führende Anbieter von Enterprise Open Source Portal Lösungen, verzeichnet eine Verdopplung seines Umsatzes sowie eine stark wachsende Nachfrage für Liferay Produkte auf dem europäischen Markt. Um diese Entwicklung zu unterstützen eröffnet Liferay einen Standort in Großbritannien, ernennt einen neuen Director of Operations für Europa und verstärkt seine Präsenz durch die Anstellung von Personal in europäischen Kernmärkten.

„Mit Freude verzeichnen wir die stetig wachsende Nachfrage für Liferay Lösungen auf dem europäischen Markt,“ sagt Bryan Cheung, CEO von Liferay. „Die Anzahl und das Interesse unserer Kunden sprechen für die deutlichen Wertvorteile unseres Produkts. Mit der Erweiterung unseres Teams und einem neuen Standort in Großbritannien ist Liferay Europa für die wachsende Nachfrage bestens positioniert.“

Die Expansion des Unternehmens in Europa folgt einem starken Fokus auf die Umsetzung einer Vertriebspartnerstrategie, die in einem 150-prozentigen Wachstum des Umsatzes in 2011 im Vergleich zum Vorjahr resultierte. In den letzten zwei Jahren hat Liferay 50 Partner in Europa dazugewonnen und so maßgebliche Fortschritte in der gesamten Region Europa erzielt. Auch in Großbritannien entwickelte sich hohes Interesse und eine stetig steigende Nachfrage nach Liferay Produkten. Während generell Open Source Lösungen auf dem lokalen Markt immer mehr Anklang finden ist insbesondere im Bereich des öffentlichen Dienstes ein hoher Bedarf zu verzeichnen. Die Eröffnung des Standortes in London ist nach den Standorten in Frankfurt am Main, Madrid und Budapest die vierte innerhalb der letzten sechs Jahre.

Herr Joseph Shum, vorher General Manager der Hauptniederlassung Liferay in Deutschland, wird Director of Operations für Europa. In seiner neuen Funktion wird Herr Shum weiterhin verstärkt die Koordination der operativen Durchführung und der Vertriebsaktivitäten zwischen den einzelnen Niederlassungen in Europa vorantreiben. Ergänzt wird das Liferay Team nun auch durch Herrn Ruud Kluivers as Senior Manager, Business Development, um die Kundenbasis in Benelux zu unterstützen und auszubauen. In Frankreich kommt Herr Marc Brassier als Alliance Manager zu Liferay um die Kunden und Partner im Land, darunter auch Banken wie Société Générale und Barclays, zu unterstützen.

Die führende Liferay Veranstaltung in Europa ist das Europe Symposium 2012 am 16.-17. Oktober in Wiesbaden, Deutschland. In der nächsten Zeit gibt es jedoch folgende Möglichkeiten, um die Portallösung und das Liferay Team in Europa kennen zu lernen:

  • Liferay Roadshow in Bilbao, Spanien – 8. Mai 2012
  • Liferay Roadshow in Oslo, Norwegen – 10. Mai 2012
  • Budapest Symposium 2012 – 17. Mai 2012
  • France Symposium 2012 – 23. Mai 2012
  • London User Group Treffen – 31. Mai 2012

Mehr Informationen und Anmeldung zu Liferay Veranstaltungen unter www.liferay.com/events. Mehr Infos über das Unternehmen und aktuelle Meldungen finden Sie auf www.liferay.com.

...

Über Liferay

Liferay, Inc. ist der führende Anbieter von Enterprise Open Source Portal und Collaboration Software Lösungen. Zu ihren Kunden gehören Fortune 500 Unternehmen wie die Allianz, BASF, Cisco Systems, Lufthansa Flight Training, Rolex SA, Siemens AG, das französische Verteidigungsministerium und die Vereinten Nationen. Liferay bietet Enterprise Edition Abonnements, die Zugang zu Emergency Fixes, Software Updates, Rund-um-die-Uhr Customer Service und andere exklusive Features beinhalten. Darüber hinaus bietet Liferay Dienstleistungen und Schulungen für die erfolgreiche Einführung des Systems und dessen individuellen Einsatz und Betrieb.

 

####

Liferay, Inc.

Rebecca Cho

1-877-LIFERAY

pr@liferay.com

PermissionChecker Explained

Company Blogs 12 de Junho de 2008 Por Joseph Shum Staff

          For my latest task I’ve been looking into re-implementing the persistence layer of Liferay permissions to authenticate users and obtain authorization data from a client identity and access management engine. In the process I thought I’d explain a little bit about the details of Liferay permissions and in this first post more specifically the PermissionChecker. How it’s implemented and where the integration points are.

So how does the portal determine what permissions to grant each user? In Liferay, permissions can be associated with a user in a few different ways. The permission can be assigned directly to a user or it can be inherited through the hierarchy of groups (with the assigned permission of course) that the user belongs to. Permissions can also be assigned to a role which then passes it on to whichever user or group has that role. Yes, quite verbose but very powerful. The PermissionChecker is where all this heavy lifting occurs and where we actually determine whether a user “has permissions” to perform certain actions. A PermissionChecker is created or borrowed from a pool and placed in the thread local and themeDisplay object on every request.

The implementation can be swapped out for your own class by extending com.liferay.portal.security.permission.PermissionCheckerImpl and overriding the necessary methods to implement your own functionality. Remember to specify your class name in portal.properties for the property permissions.checker.

Now let’s look at an example of how the PermissionChecker is used in a simple case where we want to add a new page to a community layout set. We start this explanation from within the Communities Portlet lifecycle.  We’re adding a new layout to the layout set of a Community group so a process action request gets served by EditPagesAction which is just a struts action class. The first thing that happens is a check permissions call which uses the PermissionChecker to determine whether the user has the rights to perform the action MANAGE_LAYOUTS on targeted layout set of the community group. You will see permission checks like this all over Liferay’s view and service layer classes whenever we try to perform an action on a portal object. An example of what this check might look like:

 

GroupPermissionUtil.contains(permissionChecker,group.getGroupId(), ActionKeys.MANAGE_LAYOUTS)

 

As mentioned earlier, a user can inherit a permission from a hierarchy of groups that the user belongs to or a role that is directly or indirectly associated with the user. This hierarchical complexity is handled by a class within the PermissionChecker called the PermissionCheckerBag. So what’s in the bag? On first call to perform an action the bag is actually empty (null to be technically correct). Based off the user id we grab all the Organizations and UserGroups that the user belongs to along with the corresponding Groups since all these “containers” are also represented as Groups. We also obtain and throw in the roles as well. You can think of the PermissionCheckerBag as a container for all the user’s Group and Role associations per community and also contains helper (permission shortcut) methods that determine whether a user is a community owner or admin. This object is stored for the remainder of the request and discarded when the PermissionChecker is returned to the pool. (For performance reasons we should cache this object for the entire user session. This issue is now http://support.liferay.com/browse/LEP-6273). This class can also be extended as the implementation class com.liferay.portal.security.permission.PermissionCheckerBagImpl is only used in PermissionChecker.

Now that we have the PermissionCheckerBag inside the PermissionChecker we are ready for the next step of the process, checking the bag's groups and roles for the permission to perform the action MANAGE_LAYOUTS. As with all service calls in Liferay this one begins with a *ServiceUtil helper class, in this case PermissionServiceUtil which is used to obtain the proper service via Spring. This service class can be easily swapped out in portal-spring.xml if so desired. The utility uses PermissionServiceFactory to get the PermissionService bean and its default implementation com.liferay.portal.service.impl.PermissionServiceImpl or a class that you implement yourself. In our example for adding a layout to the community layout set we first need to start by getting a list of resources scoped for Individual, Group, Group Template and Company through another service helper ResourceLocalServiceUtil (lets leave this service alone unless you are planning to offload resource management to another datastore). Resources identify the target object that you are trying to “MANAGE_LAYOUTS” on. Now with this list of resources and the PermissionCheckerBag we can do a check for the permissions we are looking for. The actual call looks like this:

 

PermissionLocalServiceUtil.hasUserPermissions(user.getUserId(), groupId, actionId, resourceIds, bag)

 

This PermissionService contains the bulk of the logic for Liferay permissions and brings together all the data gathered up to this point to perform the required queries. This call is made from the PermissionChecker and can also be customized to implement your own authorization logic if required. Again, just swap out the service implementation.

Let’s look at some of the SQL calls used to figure out permissions for a user to add a layout. First we want to find all the Permissions for the action we are performing on the resource.

 

SELECT {Permission_.*} FROM Permission_ WHERE (actionId = ?) AND (resourceId = ? OR resourceId = ? OR resourceId = ? OR resourceId = ?)  

 

Once we have all the Permissions for the action and resource we want to check to see if any of the user associations either directly or inherently has the permission. We do this via the PermissionFinder which is helper class for performing custom SQL calls for permissions. The PermissionFinder performs a custom SQL based on the permissions.user.check.algorithm specified in portal.properties and returns true if the user has an association to the permission. Of course these SQL calls are made once before they are cached in the portal for subsequent requests.

So there you have it. PermissionChecker Explained. In case anyone was wondering.

 

Mostrando 2 resultados.