I use docker on Mac OS X. On Mac OS X there is no possibility to map a domain name like mysite.local to something like http://localhost:8015/ etc.
So I have to call my docker container with http://localhost:8015/ The backend works as expected and shows me the applicationContext Development/Docker. The frontend works too, but only when i use the base entry in site.config:
base: http://localhost:8015/
works but:
baseVariants:
-
base: http://localhost:8015/
condition: 'applicationContext == "Development/Docker"'
does not.
Any ideas why or any workaround?
Thanks!
OK, i found the solution: it was a minor error in my configuration. In the htaccess file of my docker volume i wrote:
SetEnv TYPO3_CONTEXT=Development/Docker
this syntax is wrong but it works in the backend ... so TYPO3 showed me in the backend the context "Development/Docker". But it does not work in the frontend ... This syntax works:
SetEnv TYPO3_CONTEXT Development/Docker
Now my baseVariants runs as expected.
Sorry for the noise ... :-)
Related
I am stuck with a JBoss-Keycloak issue. Posting this with the hope that someone who has encountered this may have some idea on what could be going wrong. Details are below.
Environment -
OS -
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.5
BuildVersion: 18F132
JBoss EAP 7.1 - running with adapter and on localhost:8080 with hello.war deployed
Keycloak 7.0.1 - running on localhost:8180
Issue -
. Getting "404 - Not Found" for a simple hello.war (with KEYCLOAK as the auth-method in its web.xml ; keycloak.json lies beside web.xml) when accessing http://localhost:8080/hello
https://issues.jboss.org/browse/WFLY-12776
Resolved by making the module name in web.xml match the webapp name (hello) ...
<module-name>hello</module-name>
I'm trying to configure PLAIN authentification based on JPAM 1.1 and am going crazy since it doesnt work after x times checking my syntax and settings. When I start drill with cluster-id and zk-connect only, it works, but with both options of PLAIN authentification it fails. Since I started with pam4j and tried JPAM later on, I kept JPAM for this post. In general I don't have any preferences. I just want to get it done. I'm running Drill on CentOS in embedded mode.
I've done anything required due to the official documentation:
I downloaded JPAM 1.1, uncompressed it and put libjpam.so into a specific folder (/opt/pamfile/)
I've edited drill-env.sh with:
export DRILLBIT_JAVA_OPTS="-Djava.library.path=/opt/pamfile/"
I edited drill-override.conf with:
drill.exec: {
cluster-id: "drillbits1",
zk.connect: "local",
impersonation: {
enabled: true,
max_chained_user_hops: 3
},
security: {
auth.mechanisms: ["PLAIN"],
},
security.user.auth: {
enabled: true,
packages += "org.apache.drill.exec.rpc.user.security",
impl: "pam",
pam_profiles: [ "sudo", "login" ]
}
}
It throws the subsequent error:
Error: Failure in starting embedded Drillbit: org.apache.drill.exec.exception.DrillbitStartupException: Problem in finding the native library of JPAM (Pluggable Authenticator Module API). Make sure to set Drillbit JVM option 'java.library.path' to point to the directory where the native JPAM exists.:no jpam in java.library.path (state=,code=0)
I've run that *.sh file by hand to make sure that the necessary path is exported since I don't know if Drill is expecting that. The path to libjpam should be know known. I've started Sqlline with sudo et cetera. No chance. Documentation doesn't help. I don't get it why it's so bad and imo incomplete. Sadly there is 0 explanation how to troubleshoot or configure basic user authentification in detail.
Or do I have to do something which is not told but expected? Are there any Prerequsites concerning PLAIN authentification which aren't mentioned by Apache Drill itself?
Try change:
export DRILLBIT_JAVA_OPTS="-Djava.library.path=/opt/pamfile/"
to:
export DRILL_JAVA_OPTS="$DRILL_JAVA_OPTS -Djava.library.path=/opt/pamfile/"
It works for me.
I am using:
wildlfy 10.1.0 final
Camel 2.19.1
Camel Java DSL RouteBuilder
In my RouteBuilder.configure I have the following from:
from("undertow:http://localhost:" + portNum + "/DataplatformESB/v3?matchOnUriPrefix=true&httpMethodRestrict=post,get,put,options,patch,delete")
When I test to "localhost:8080/DataplatformESB/v3" with GET, PUT, or PATCH, they all work fine. But when I test to "localhost:8080/DataplatformESB/v3/anythingelse" I'll get a 404 (page not found) in return. In the Wildfly log it stats: "Matched prefix path /DataplatformESB for path /DataplatformESB/v3/anythingelse". So for me it looks like the "matchOnUriPrefix=true" is not working.
I have already tested with from("restlet:http://localhost:" + portNum + "/DataplatformESB/v3?matchOnUriPrefix=true&httpMethodRestrict=post,get,put,options,patch,delete"), but that does not work as well.
I have also tried it with the restConfiguration and .componentProperty("matchOnUriPrefix", "true") but also no luck.
Does anyone has an idea why the matchOnUriPrefix=true does not seem to work for me?
I have done some further research and found out the folliwing:
I got the undertow test project from https://github.com/apache/camel/tree/master/components/camel-undertow/src/test/java/org/apache/camel/component/undertow/UndertowPrefixMatchingTest.java and run/tested in it in my NetBeans.
The code is:
from("undertow:http://localhost:{{port}}/bar?matchOnUriPrefix=true")
.transform(bodyAs(String.class).append(" Matching prefix"))
.to("mock:bar");
This runs fine and returns OK when the URL starts with the prefix: "bar". So "bar/foo" returns OK as well.
But when I paste this code into the Wildfly Camel Rest Swagger example (there is no Wildfly Camel Rest example) from the website https://github.com/wildfly-extras/wildfly-camel-examples/tree/master/camel-rest-swagger, then I only get an OK when testing with "bar" as path.
Using "bar/foo" result in a 404 return code.
Im still using Wildfly 10.1 final and Camel 2.19.1.
So what is causing the difference in output? What do I have to change in Wildfly to get it working?
Is the option matchOnUriPrefix default disabled/ignored on Wildfly?
When using the Wildfly-Camel 2.18.3 on the Wildlfly installation it seems to work.
It looks like the default value for matchOnUriPrefix is changed or the handling of this property.
In that case it seems to me that this introduced the bug as described above.
I am getting the following warning in my code:
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php/./views/helpers/Doctype.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
or
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php//var/www/virtual/example.com/htdocs/rockhopper-v2/application/modules/default/views/helpers/Layout.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
what is the problem and will it cause problems in deployment and production stage of my application?
Thank you
This message appears because since Zend FW 1.10.1 the autoloader creates the path to those files differently. You can find some more information here: Zend FW Bug Report
To get rid of this message you can edit the file index.php and change the set_include_path to this:
set_include_path(
APPLICATION_PATH.'/../library'.PATH_SEPARATOR.
APPLICATION_PATH.'/../library/Zend'
);
open_basedir is set php is running in safe mode. It restricts you to the folders specified in the list. This might help: http://blog.php-security.org/archives/72-Open_basedir-confusion.html
And yes, you will need to change it on any server if you want to access files outside the default folder.
I am trying to get Portable Allegro Serve and Webactions up and running on SBCL. I have so far managed to make paserve properly serve pages. But webactions chunks out with the following warning in the console:
1-aserve-worker: 05/27/09 - 21:28:43 - processing clp file "/home/user/pages/index.html" got error The value NIL
is not of type
FUNCTION.
1-aserve-worker: 05/27/09 - 21:28:43 - while processing command "GET /testing/index.html HTTP/1.0"
got error The slot NET.ASERVE::OBJECTS is unbound in the object #<NET.ASERVE:CLP-ENTITY {C1C8201}>.
Any ideas as to why this is happening? Alternatively any ideas on how I could break into this to examine/investigate what is going on?
Versions of software: SBCL 1.0.28 running on debian 2.6.26, PAServe 1.2.47.
It seems the acl-compat library which comes with asdf-install is different from the acl-compat library that comes with paserve.
I never resolved the above problem, but using a different acl-compat layer made the problem disappear.