I would like my server to point to resource files (i.e. css, js, images that are under /resources/default/VERSION_NUMBER/) to AWS S3 instead of delivering the files to the client side by itself.
Here are the relevant libraries and their version number taken from the pom file:
<javax.servlet-api.version>3.0.1</javax.servlet-api.version>
<weld-servlet.version>2.2.9.Final</weld-servlet.version>
<javax.el-api.version>3.0.0</javax.el-api.version>
<el-impl.version>2.2</el-impl.version>
<tomcat-jdbc.version>7.0.47</tomcat-jdbc.version>
<javax.faces.version>2.2.10</javax.faces.version>
<omnifaces.version>2.3</omnifaces.version>
<primefaces.version>6.1</primefaces.version>
I took a look at this post and modified my web.xml file with the following lines:
<context-param>
<param-name>org.omnifaces.CDN_RESOURCE_HANDLER_URLS</param-name>
<param-value>
remote:*=https://[URL]
</param-value>
</context-param>
And updated the library tag in all my css, javascript and image files mentioned in my xhtml file accordingly.
example:
<h:outputStylesheet library="default" name="styles/header.css"/>
Is modified to
<h:outputStylesheet library="remote" name="styles/header.css"/>
Now I am noticing that while the css files are loaded properly from the remote server, the url tags such the following present in the css files (hosted on the remote server) are not being downloaded from the local or remote server
background-image: url("#{resource['remote:images/add-default.png']}") !important;
Note that everything under my resource folder is already hosted in my remote server. I imagine JSF is failing to properly create the url from #{resource['remote:images/add-default.png'}] because in firefox console I get the error "The resource at “” was blocked because content blocking is enabled." for these files.
Once I figure out how to fix this, I would also like to know how to make it so all the jsf resources required on the client side that I don't explicitly specify in my xhtml files can be also hosted in the remote server.
Thank you!
Related
One of the views (.cshtml file) of my ASP.NET MVC application is using A-Frame. I am trying to load a 3-D model using GLTF file inside the <a-scene> tag.
<body>
<a-scene>
<a-assets timeout="5000">
<a-asset-item id="tree" src="~/Assets/scene.gltf">
</a-assets>
<a-gltf-model src="#tree"></a-gltf-model>
</a-scene>
</body>
I have already tested the src path in the same page by putting a .png file and loading it in <img/>, it works. The problem is just with the .gltf file.
What is possibly wrong with the .gltf file in particular?
The URL doesn't seem like a valid URL. It seems like a Unix path. Host the GLTF somewhere the website can reach it (like the same directory) and fix the path. src="scene.gltf".
I'm using OmniFaces CDNResourceHandler to point my resources to a CDN, instead of local files.
I added this line in my XHTML file: <h:outputStylesheet library="twitter-bootstrap" name="bootstrap.min.css" />
And my faces-config.xml have this line:
<context-param>
<param-name>org.omnifaces.CDN_RESOURCE_HANDLER_URLS</param-name>
<param-value>
twitter-bootstrap:bootstrap.min.css=https://somehost/twitter-bootstrap/3.3.7/bootstrap.min.css
</param-value>
</context-param>
And I'm getting this error when access the page:
Unable to find resource twitter-bootstrap, bootstrap.min.css
Note: When I access the file at https://somehost/twitter-bootstrap/bootstrap.min.css I can download the file properly.
I'm using Mojarra under Wildfly configured to Development stage.
The resource handler is properly configured at faces-config.xml file.
<application>
<resource-handler>org.omnifaces.resourcehandler.CDNResourceHandler</resource-handler>
</application>
I did some tests, and I notice that the error doesn't occurs if I create an empty file bootstrap.min.css under WEBAPP_FOLDER/resources/twitter-bootstrap. If I delete the file, the errors occurs again.
Even I use CDN, do I need to keep resources locally?
The CDNResourceHandler is primarily intented to move auto-included JSF resources to a CDN, such as jsf.js file from <f:ajax>, or primefaces.js and jquery.js from PrimeFaces, or to automatically switch to a CDN when installed in production.
You don't need it in your case with a permanent CDN resource. Just use plain <link>.
<link rel="stylesheet" src="https://somehost/twitter-bootstrap/bootstrap.min.css" />
This is also explicitly mentioned in the CDNResourceHandler documentation.
For non-JSF resources, you can just keep using plain HTML <script> and <link> elements referring the external URL
Update: as you're not the first one who wondered about this, I've as per issue 122 bypassed this technical restriction for OmniFaces 2.6. In other words, you do not necessarily need a local resource anymore.
I have deployed Liferay 6.2 GA4 portal on WebLogic server 10.3.6.0. If the javascript.fast.load property is enabled, the packed javascript version is not got (downloaded) from /combo url. In web browser console the following errors are displayed:
GET https://www.mywebsite.cz/liferay-portal/combo/?browserId=other&minifierType=&languageId=en_US&b=6203&t=1448975784000&/liferay-portal/html/js/aui/color-base/color-base-min.js&/liferay-portal/html/js/aui/event-touch/event-touch-min.js&/liferay-portal/html/js/liferay/dockbar.js 404 (Not Found)
Uncaught TypeError: Cannot read property 'init' of undefined
Due to this for example dockbar doesn't work. From source code it looks like ComboServlet can't get servlet resources found in /combo url parameters. If javascript.fast.load is disabled, portal seems to work.
Weblogic.xml:
<weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd"
>
<jsp-descriptor>
<keepgenerated>true</keepgenerated>
<page-check-seconds>60</page-check-seconds>
</jsp-descriptor>
<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>
<container-descriptor>
<prefer-application-packages>
<package-name>antlr.*</package-name>
<package-name>com.ctc.wstx.*</package-name>
<package-name>org.antlr.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.mozilla.*</package-name>
<package-name>org.xmlpull.*</package-name>
</prefer-application-packages>
<optimistic-serialization>true</optimistic-serialization>
<show-archived-real-path-enabled>true</show-archived-real-path-enabled>
</container-descriptor>
<context-root>/liferay-portal</context-root>
<library-ref>
<library-name>ext-portal-dependencies</library-name>
<specification-version>1.0</specification-version>
<implementation-version>1.0</implementation-version>
<exact-match>false</exact-match>
</library-ref>
</weblogic-web-app>
Does anybody know what could be the problem? Some WebLogic or Liferay settings? Thanks for any idea or help.
I've had a comparable problem long ago on tomcat when there were problems with the temporary file path - e.g. it growing too long. This might happen in a deeply nested filesystem, or when the total path length is limited.
One of the path-length-limiting factors that I'm aware of is an encrypted home folder on Linux. Also, if the temporary filesystem runs full, the compressed file won't be written and consequently can't be served to the browser.
Check something along those lines, and please report back.
After several days of solving the problem I found the main cause of this problem was this:
Because the customer didn't want to have portal dependencies (portal-service.jar, portlet-api.jar, ...) as domain libraries, I deployed it as Java EE Shared Libraries. Obviously it works differently than I expected. So after persuasion of customer, I put liferay dependencies to domain lib folder and suddenly everything started to work.
Is it possible for someone to access or view the web.xml file of a web application over internet, using somthing like wget tool? I'm asking for saecurity reasons like username
By specification, it is not possible to directly access /WEB-INF (and /META-INF) contents by a public URL. Here are extracts of relevance from the aforelinked specification:
10.5 Directory structure
...
Also, except
for the case where static resources are packaged in JAR files, any requests from the
client to access the resources in WEB-INF/ directory must be returned with a
SC_NOT_FOUND(404) response.
10.6 Web Application Archive File
...
Also, any requests to access the resources in META-INF
directory must be returned with a SC_NOT_FOUND(404) response.
However, there have been implementations, configurations and even homegrown servlets or filters which introduced a security bug making this possible. All those security issues boil down to be caused by a RequestDispatcher#forward() or even RequestDispatcher#include() (so watch out with dynamic <jsp:include>!) call forwarding or including a resource which is specified by a client-controlled request path or parameter, if necessary making use of path traversal with ../.
Here's the simplest example of such a servlet exposing the security issue:
#WebServlet("/test/*")
public class TestServlet extends HttpServlet {
#Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
request.getRequestDispatcher(request.getPathInfo()).forward(request, response);
}
}
On Tomcat (tested with 8.0.21), you can with the above servlet get the web.xml contents by just calling http://localhost:8080/context/test/WEB-INF/web.xml. Such a servlet is often implemented as part of homegrown MVC front controller or dispatcher pattern. Decent MVC frameworks like JSF and Spring MVC shouldn't have this issue.
And, some users configure a MVC front controller on a "catch-all" URL pattern of /* or even /, and then re-map the static resources like CSS/JS/images on /static/* to container's default servlet like so:
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/static/*</url-pattern>
</servlet-mapping>
On older Tomcat versions (before 7.0.4), the enduser can get /WEB-INF (and /META-INF) contents through such a mapping. This problem was mentioned previously in this Q&A: Tomcat serving static content. Actually, this mapping approach is wrong and should have been solved with help of a filter as descibed in this answer: How to access static resources when mapping a global front controller servlet on /*. See also Tomcat issue 50026.
Summarized: by default it's not possible. But (bad) code and configuration can make this possible.
Hello trying to figure out the Jsf (primefaces) and little that goes viz. Compiled war archive in maven try to run through the Glassfish, the server starts but in the beginning writing "Artifact qwe-1.0-SNAPSHOT.war: Server is not connected. Deploy is not available." But in the late writes "Artifact qwe-1.0-SNAPSHOT.war: Artifact is being deployed, please wait... Artifact is deployed successfully." It seems like everything is normal, then opened my page in the browser is empty although in my index.xhtm and my pom.xml and web.xml link pastebin
and should be a button with styles that are connected in primefaces tell me if I'm doing something wrong?
here's a screenshot of the result in the browser. link1
<p:button outcome="productDetail" value="Bookmark" icon="ui-icon-star"> targets you to the productDetail page. If you do not have productDetail.xhtml page at the currect path, the index.xhtml page cannot resolve NavigationCase for outcome. Thus, Create page productDetail.xhtml and put into the same directory of index.xhtml.
In addition, You should use JSF Standard tags(h:head, h:body).