We can access HMC in JUnit tenant by hitting the below URL
https://localhost:9002/hmc_junit/hybris
which is defined in tenant_junit.properties like this hmc.webroot=/hmc_junit
But I havn't seen anywhere URL to access Backoffice in JUnit Tenant.
Can anybody help me please to access Backoffice in JUnit Tenant ?
I was looking for it everywhere as well, couldn't find any documentation in the wiki... It doesn't seem to be officially supported but here is what I found.
Under Hybris 6.3 there is no junit context path for the backoffice application. Here is how you could add one :
Create a file named : local_tenant_junit.properties under your configuration folder, it should contain :
backoffice.webroot=/backoffice_junit
Create a file for customization inside your config folder customize/ext-backoffice/backoffice/web/webroot/WEB-INF/backoffice-spring-filter.xml. Copy the content of the original file and update the backofficeFilterChain bean. We want to use the dynamicTenantActivationFilter instead of the tenantActivationFilter) :
<bean id="backofficeFilterChain" class="de.hybris.platform.servicelayer.web.PlatformFilterChain">
<constructor-arg>
<list>
<ref bean="log4jFilter"/>
<ref bean="dynamicTenantActivationFilter"/>
<ref bean="backofficeRedirectFilter"/>
<ref bean="sessionFilter"/>
<ref bean="backofficeDataSourceSwitchingFilter"/>
<ref bean="backofficeCatalogVersionActivationFilter"/>
<ref bean="backofficeContextClassloaderFilter"/>
<ref bean="backofficeSecureMediaFilter" />
</list>
</constructor-arg>
Execute ant clean all customize
Check that in bin/platform/tomcat/conf/server.xml you now have a new context backoffice_junit
Start your server, you can now access the backoffice application for master and junit tenant
For Hybris 6.7, to me the following steps were sufficient:
in config/local_tenant_junit.properties , add
backoffice.webroot=/backoffice_junit
ant server
this puts the endpoint into ${tomcat.webapps} in server.xml template resulting in:
<Context path="/backoffice_junit"...
being added to your bin/platform/tomcat/conf/server.xml
Then when you open https://localhost:9002/backoffice_junit , the DataSourceSwitchingFilter gets current tenant from a ThreadLocal and activates its dataSource.
Config values inside the junit local properties that worked for me:
backoffice.library.home=${data.home}/junit
backoffice.webroot=/junit_backoffice
For more info see:
https://help.sap.com/viewer/5c9ea0c629214e42b727bf08800d8dfa/1811/en-US/c7e1bf2832414c8ea15c001d5cf1defd.html
Related
I have the same problem as several other questions here, none of which have really been answered; that is, with CAS 4.x (4.2.6 actually) I cannot get LDAP attributes to return to the client application.
Question 1 This seems like overkill; custom code to get around what is a "simple" problem.
Question 2 Had already done this, and it didn't work.
So, now it's my turn to ask... is there some magic to making it work? We've used 3.5 for a long time without any issues. I'm trying to convert those settings to the 4.x Maven overlayer and new context configuration of 4.x, and it's not doin' it.
I can see in the logs that CAS is requesting, and getting the properties I'm looking for from LDAP. But they are not getting put in the token back to the application.
What more needs to be done beyond what the Apereo documentation lays out? I'm thinking it's the attribute repository maybe??? If something would help you help me through this, just ask: Config, Logs (redacted of course)... anything.
Thanks.
Update #1. Here is my resolvers list. NOTE: I keep code/settings in place commented out until I get it to work before I clean stuff out.
<util:map id="authenticationHandlersResolvers">
<!--
<entry key-ref="proxyAuthenticationHandler" value-ref="proxyPrincipalResolver" />
<entry key-ref="primaryAuthenticationHandler" value-ref="primaryPrincipalResolver" />
-->
<!--<entry key-ref="ldapAuthenticationHandler" value-ref="primaryPrincipalResolver" /> -->
<entry key-ref="ldapAuthenticationHandler" value="#{null}" />
</util:map>
Update #2
I've done more testing, and still am unsuccessful. I think, it's coming down to the principalAttributeMap of the LdapAuthenticationHandler not working, OR, the attributeReleasePolicy of the serviceRegistryDao... anyone see any issues in this config?
<bean id="ldapAuthenticationHandler" class="org.jasig.cas.authentication.LdapAuthenticationHandler"
p:principalIdAttribute="sAMAccountName"
c:authenticator-ref="authenticator"
>
<property name="principalAttributeMap">
<map>
<entry key="cn" value="cn" />
<entry key="mail" value="Email" />
<entry key="memberOf" value="Groups" />
<entry key="displayName" value="displayName" />
</map>
</property>
</bean>
<bean id="serviceRegistryDao" class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
<property name="registeredServices">
<list>
<bean class="org.jasig.cas.services.RegexRegisteredService"
p:id="5"
p:name="All Servicesxxx"
p:description="Allow connections for all services and protocols"
p:serviceId="^(http|https|imaps)://.*"
p:evaluationOrder="5"
>
<property name="attributeReleasePolicy">
<bean class="org.jasig.cas.services.ReturnAllAttributeReleasePolicy" />
</property>
</bean>
</list>
</property>
</bean>
To quote from CAS Security Guide:
All communication with the CAS server MUST occur over a secure channel
(i.e. TLSv1). There are two primary justifications for this
requirement:
The authentication process requires transmission of security
credentials.
The CAS ticket-granting ticket is a bearer token.
Since the disclosure of either data would allow impersonation attacks, it’s
vitally important to secure the communication channel between CAS
clients and the CAS server.
Practically, it means that all CAS urls must use HTTPS, but it also
means that all connections from the CAS server to the application must
be done using HTTPS:
when the generated service ticket is sent back to the application on the “service” url when a
proxy callback url is called.
HTTPS is a must in CAS. However, there are possibilities to disable it but it is highly recommended not to do so. If you have struggle to handle the SSL configuration, I recommend you read my question where I explain in detail how to deal with the keystores.
we are facing an issue where a custom webpart is alreay deployed in sharepoint and when we are trying to update its EmptyMessage Property and redeploying it, its not reflecting in UI,however, we can see the .webpart file has updated with new value. here is the code snippet of .webpart file
<property name="TitleUrl" type="string" />
<property name="EmptyMessage" type="string">Currently there are no features available. Please check back.</property>
<property name="ShowBestBets" type="bool">True</property>
<property name="ShowViewDuplicates" type="bool">True</property>
<property name="AllowHide" type="bool">False</property>
We're using ctx.ClientControl.get_emptyMessage() to read this property value.
This is by design.
[filename].webpart is just a template for web part instances in the pages. Existing pages save their web part parameters once the web parts are added in the pages. Web part properties in a particular page have no link back to the .webpart file.
I wrote an interceptor in one of my projects to intercept all the requests. So usually in a spring project i will do normal build and start the server and my changes related to an interceptor will start reflecting. However this doesn't seem to be the case with a hybris project.
Do I need to do update in hybris hac as well? And if I do then out of the available below mentioned options which options do i need to choose and why.
1. Update running system
2. Clear the hMC configuration from the database
3. Create essential data
4. Localize types
Thanks,
Ashish
To answer the second part of your question, I have listed at least one reason for selecting each type of options. Hope this helps.
Update running system - Required when hybris type definition changes. For example, changing the content of file <extnesion-name>-items.xml
Clear the hMC configuration from the database - If you have chosen to persist hmc configuration in the Database and changing it. For example, changing content in the file hmc.xml
Create essential data - If there is a change in the content in the impex files which follows the naming pattern of essentialdata*.impex.
Localize types - If there is a change in the properties files for localizations. for example changing the content in file <extension-name>-locales_en.properties
Assuming you've not made any changes to any underlying data objects (Jalo items) then you won't need to run an update in the hybris hAC.
You should just be able to make your changes, run ant clean all from the platform and then start up the hybris ECP instance and your changes will be visible.
If this is a normal Spring MVC interceptor, then it should work fine.
Have you checked your spring configuration in the storefront extension you are working from?
For example, take a look at the accelerator Spring MVC configuration file:
hybris/bin/ext-template/yacceleratorstorefront/web/webroot/WEB-INF/config/spring-mvc-config.xml
This has some examples where this is used out-of-the-box:
<mvc:interceptors>
<ref bean="beforeControllerHandlerInterceptor" />
<ref bean="beforeViewHandlerInterceptor" />
<ref bean="csrfHandlerInterceptor" />
</mvc:interceptors>
As an example, the default before controller handler interceptor is defined as:
<!-- Interceptor that runs once per request and before the controller handler method is called -->
<alias name="defaultBeforeControllerHandlerInterceptor" alias="beforeControllerHandlerInterceptor" />
<bean id="defaultBeforeControllerHandlerInterceptor" class="de.hybris.platform.yacceleratorstorefront.interceptors.BeforeControllerHandlerInterceptor" >
<property name="beforeControllerHandlers">
<ref bean="beforeControllerHandlersList" />
</property>
</bean>
which references:
<alias name="defaultBeforeControllerHandlersList" alias="beforeControllerHandlersList" />
<util:list id="defaultBeforeControllerHandlersList" >
<!-- List of handlers to run -->
<bean class="de.hybris.platform.yacceleratorstorefront.interceptors.beforecontroller.SecurityUserCheckBeforeControllerHandler" />
<bean class="de.hybris.platform.yacceleratorstorefront.interceptors.beforecontroller.RequireHardLoginBeforeControllerHandler" >
<property name="userService" ref="userService"/>
<property name="redirectStrategy" ref="redirectStrategy"/>
...
</bean>
<bean class="de.hybris.platform.yacceleratorstorefront.interceptors.beforecontroller.DeviceDetectionBeforeControllerHandler" />
...
</util:list>
So you could either override this using the alias with your own implementation, or add additional controller handlers to the list.
As there is no change to the underlying data model - this is just wiring up Spring MVC related classes - no need for an update system or anything like that. Just an 'ant clean all' to recompile to pick up your new interceptor classes, and server restart to pick up the change in the Spring cornfiguraton.
I am having trouble with configuring a webapp in Tomcat 7. In my WAR file, there is a properties file myApp/WEB-INF/classes/myProps.props, and it contains environment-specific properites. I am trying to override that configuration file on the server, so that the same WAR file will deploy to multiple environments.
I heard there was a way to do this using replacement config files in tomcat/conf/Catalina/myApp. This is the method I am having trouble figuring out.
Also, myApp.war is one of many running on the same Tomcat server, and it does not run as localhost. I want to be able to solve this problem for several of the webapps.
Server version: Apache Tomcat/7.0.23
Server built: Nov 20 2011 07:36:25
Server number: 7.0.23.0
OS Name: Linux
Your tomcat/conf/Catalina/<host> can contain context descriptors that let you configure lots of things including defining "environment entries", which are accessible from Java via JNDI. There are lots of ways to go about using it. Personally, I set an environment entry which is the file system path to my properties file. My app is built to check for this entry, and if it doesn't exist, look for the file on the classpath instead. That way, in dev, we have the dev properties right there on the classpath, but when we build and deploy, we point it to an external file.
There's good documentation for configuring a context on the Tomcat website. See the Defining a Context section on details of how to create the file and where to put it.
As an example, if your host is named myHost and your app is a war file named myApp.war in the webapps directory, then you could create tomcat/conf/Catalina/myHost/myApp.xml with this content:
<Context>
<Environment name="configurationPath" value="/home/tomcat/myApp.properties" type="java.lang.String"/>
</Context>
Then from your code, you'd do a JNDI lookup on java:comp/env/configurationPath (95% certainty here) to get that string value.
I like .properties files instead of
JNDI - why build complex object during program configuration instead of initialization time?
system properties - you can't separately configure several instances of same WAR in single Tomcat
context parameters - they accessible only in javax.servlet.Filter, javax.servlet.ServletContextListener which my be inconvenient
Tomcat 7 Context hold Loader element. According to docs deployment descriptor (what in <Context> tag) can be placed in:
$CATALINA_BASE/conf/server.xml - bad - require server restarts in order to reread config
$CATALINA_BASE/conf/context.xml - bad - shared across all applications
$CATALINA_BASE/work/$APP.war:/META-INF/context.xml - bad - require repackaging in order to change config
$CATALINA_BASE/work/[enginename]/[hostname]/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/webapps/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/conf/[enginename]/[hostname]/$APP.xml - best - completely out of application and automatically scanned for changes!!!
Context can hold custom Loader org.apache.catalina.loader.VirtualWebappLoader (available in modern Tomcat 7, you can add own separate classpath to your .properties), and Parameter (accessed via FilterConfig.getServletContext().getInitParameter(name)) and Environment (accessed via new InitialContext().lookup("java:comp/env").lookup("name")):
<Context docBase="${basedir}/src/main/webapp"
reloadable="true">
<!-- http://tomcat.apache.org/tomcat-7.0-doc/config/context.html -->
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/WEB-INF/classes=${basedir}/target/classes,/WEB-INF/lib=${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="${basedir}/target/classes;${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<JarScanner scanAllDirectories="true"/>
<Parameter name="min" value="dev"/>
<Environment name="app.devel.ldap" value="USER" type="java.lang.String" override="true"/>
<Environment name="app.devel.permitAll" value="true" type="java.lang.String" override="true"/>
</Context>
If you use Spring and it's XML config:
<context:property-placeholder location="classpath:app.properties"/>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="oracle.jdbc.OracleDriver"/>
<property name="url" value="jdbc:oracle:thin:#${db.host}:${db.port}:${db.user}"/>
<property name="username" value="${db.user}"/>
<property name="password" value="${db.pass}"/>
</bean>
With Spring injecting above properties into bean fields are easy:
#Value("${db.user}") String defaultSchema;
instead of JNDI:
#Inject ApplicationContext context;
Enviroment env = context.getEnvironment();
String defaultSchema = env.getProperty("db.user");
Note also that EL allow this (default values and deep recursive substitution):
#Value('${db.user:testdb}') private String dbUserName;
<property name='username' value='${db.user.${env}}'/>
See also:
Adding a directory to tomcat classpath
Can I create a custom classpath on a per application basis in Tomcat
How to read a properties file outside my webapp context in Tomcat
Configure Tomcat to use properties file to load DB connection information
Should you set up database connection properties in server.xml or context.xml
Externalize Tomcat configuration
NOTE With extending classpath to live directory you also allowed to externilize any other configs, like logging, auth, atc. I externilize logback.xmlin such way.
UPDATE Tomcat 8 change syntax for <Resources> and <Loader> elements, corresponding part now look like:
<Resources>
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/classes" base="${basedir}/target/classes" />
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/lib" base="${basedir}/target/${project.build.finalName}/WEB-INF/lib" />
</Resources>
You can try to place your configuration (properties file) in Apache Tomcat\lib in JAR file and remove it from the web application. When the Tomcat's class loader won't find your config in webapp it will try to find in "lib" directory. So you can externalize your configuration just moving the config to global lib dir (it's shared among other webapps).
I just added a setenv.bat or setenv.sh script in the bin folder of tomcat. Set the classpath variable like
set CLASSPATH=my-propery-folder
I'm using the MOSS Minimal Publishing Site Definition from codeplex.
I want to change the default.aspx page to be a publishing page by default, rather than a WSS page as it is currently in this site definition.
Is that possible?
To implement this in the web UI:
You need to create a new page within your publishing site, and then set that page as the 'Welcome' page within Site Settings.
Essentially this will overide the default.aspx and use your new publishing page as the initial opening page for your site.
To implement this for a site definintion:
You need to create a feature which deploys an instance of your initial page to the pages library and then sets the welcome page using the object model (probably using a FeatureReceiver).
More info on how to do this here:
http://www.devexpertise.com/2009/02/02/setting-the-welcome-page-in-wss-30/
You can use the following also (the example is with FeatureStapling):
<!-- Publishing feature -->
<FeatureSiteTemplateAssociation Id="22A9EF51-737B-4ff2-9346-694633FE4416" TemplateName="TEMPLATENAME#NUMBER">
<Property Key="ChromeMasterUrl" Value="~SiteCollection/_catalogs/masterpage/YOURMASTERPAGE.master"/>
<Property Key="WelcomePageUrl" Value="YOURDEFAULTPAGE.aspx"/>
<Property Key="PagesListUrl" Value=""/>
<Property Key="AvailableWebTemplates" Value="ALLOWED_TEMPLATES"/>
<Property Key="AvailablePageLayouts" Value="PAGELAYOUTS"/>
<Property Key="AlternateCssUrl" Value="" />
<Property Key="SimplePublishing" Value="true" />
</FeatureSiteTemplateAssociation>