Trouble using h:link to navigate to page with non-default suffix - jsf

I've got a JSF 2 application running on glassfish and have just installed the caucho
quercus PHP implementation. With just a little configuration I can successfully serve
.php files from the server:
<servlet>
<servlet-name>Quercus Servlet</servlet-name>
<servlet-class>com.caucho.quercus.servlet.QuercusServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Quercus Servlet</servlet-name>
<url-pattern>*.php</url-pattern>
</servlet-mapping>
What I'm not able to do is use h:link to navigate to a page that doesn't use the
default suffix (.xhtml). So when I have:
<h:link outcome="/hello.php"/>
I just get a WARNING: JSF1090: Navigation case not resolved for component j_idt48 in the server log (when the page is loaded), and no amount of fiddling with leading / seems to help. Is there a way to get h:link to work in this way or should I just use h:outputLink?
Thanks.

<h:link> is for JSF navigation cases only, and thus indeed can't be used to navigate to other kind of resources, even when those are served by Servlets in the same application (like *.php in this case).
As you already suggested yourself, just use <h:outputLink>.

Related

Username not displayed after a successful login with Spring Security and Java Server Faces [duplicate]

I have some Facelets files like below.
WebContent
|-- index.xhtml
|-- register.xhtml
|-- templates
| |--userForm.xhtml
| `--banner.xhtml
:
Both pages are using templates from /templates directory. My /index.xhtml opens fine in browser. I get the generated HTML output. I have a link in /index.xhtml file to /register.xhtml file.
However, my /register.xhtml is not getting parsed and returns as plain XHTML / raw XML instead of its generated HTML output. All EL expressions in form of #{...} are displayed as-is instead of that their results are being printed. When I rightclick page in browser and do View page source, then I still see the original XHTML source code instead of the generated HTML output. For example, the <h:body> did not become a <body>. It looks like that the template is not being executed.
However, when I open the /register.xhtml like /faces/register.xhtml in browser's address bar, then it displays correctly. How is this caused and how can I solve it?
There are three main causes.
FacesServlet is not invoked.
XML namespace URIs are missing or wrong.
Multiple JSF implemenations have been loaded.
1. Make sure that URL matches FacesServlet mapping
The URL of the link (the URL as you see in browser's address bar) has to match the <url-pattern> of the FacesServlet as definied in web.xml in order to get all the JSF works to run. The FacesServlet is the one responsible for parsing the XHTML file, collecting submitted form values, performing conversion/validation, updating models, invoking actions and generating HTML output. If you don't invoke the FacesServlet by URL, then all you would get (and see via rightclick, View Source in browser) is indeed the raw XHTML source code.
If the <url-pattern> is for example *.jsf, then the link should point to /register.jsf and not /register.xhtml. If it's for example /faces/*, like you have, then the link should point to /faces/register.xhtml and not /register.xhtml. One way to avoid this confusion is to just change the <url-pattern> from /faces/* to *.xhtml. The below is thus the ideal mapping:
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
If you can't change the <url-pattern> to *.xhtml for some reason, then you probably would also like to prevent endusers from directly accessing XHTML source code files by URL. In that case you can add a <security-constraint> on the <url-pattern> of *.xhtml with an empty <auth-constraint> in web.xml which prevents that:
<security-constraint>
<display-name>Restrict direct access to XHTML files</display-name>
<web-resource-collection>
<web-resource-name>XHTML files</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
JSF 2.3 which was introduced April 2017 has already solved all of above by automatically registering the FacesServlet on an URL pattern of *.xhtml during webapp's startup. The alternative is thus to simply upgrade to latest available JSF version which should be JSF 2.3 or higher. But ideally you should still explicitly register the FacesServlet on only one URL pattern of *.xhtml because having multiple possible URLs for exactly the same resource like /register.xhtml, /register.jsf, /register.faces and /faces/register.xhtml is bad for SEO.
See also:
Set default home page via <welcome-file> in JSF project
Opening JSF Facelets page shows "This XML file does not appear to have any style information associated with it."
Sometimes I see JSF URL is *.jsf, sometimes *.xhtml and sometimes /faces/*. Why?
JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used
Which XHTML files do I need to put in /WEB-INF and which not?
Our servlets wiki - to learn the mandatory basics about servlets
2. Make sure that XML namespaces match JSF version
Since introduction of JSF 2.2, another probable cause is that XML namespaces don't match the JSF version. The xmlns.jcp.org like below is new since JSF 2.2 and does not work in older JSF versions. The symptoms are almost the same as if the FacesServlet is not invoked.
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
If you can't upgrade to JSF 2.2 or higher, then you need to use the old java.sun.com XML namespaces instead:
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
But ideally you should always use the latest version where available.
See also:
Which XML namespace to use with JSF 2.2 and up
JSF tags not executed
Warning: This page calls for XML namespace http://xmlns.jcp.org/jsf/XXX declared with prefix XXX but no taglibrary exists for that namespace
3. Multiple JSF implementations have been loaded
One more probable cause is that multiple JSF implementations have been loaded by your webapp, conflicting and corrupting each other. For example, when your webapp's runtime classpath is polluted with multiple different versioned JSF libraries, or in the specific Mojarra 2.x + Tomcat 8.x combination, when there's an unnecessary ConfigureListener entry in webapp's web.xml causing it to be loaded twice.
<!-- You MUST remove this one from web.xml! -->
<!-- This is actually a workaround for buggy GlassFish3 and Jetty servers. -->
<!-- When leaving this in and you're targeting Tomcat, you'll run into trouble. -->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
When using Maven, make absolutely sure that you declare the dependencies the right way and that you understand dependency scopes. Importantingly, do not bundle dependencies in webapp when those are already provided by the target server.
See also:
Configuration of com.sun.faces.config.ConfigureListener
How to properly install and configure JSF libraries via Maven?
Make sure that you learn JSF the right way
JSF has a very steep learning curve for those unfamiliar with basic HTTP, HTML and Servlets. There are a lot of low quality resources on the Internet. Please ignore code snippet scraping sites maintained by amateurs with primary focus on advertisement income instead of on teaching, such as roseindia, tutorialspoint, javabeat, baeldung, etc. They are easily recognizable by disturbing advertising links/banners. Also please ignore resources dealing with jurassic JSF 1.x. They are easily recognizable by using JSP files instead of XHTML files. JSP as view technology was deprecated since JSF 2.0 at 2009 already.
To get started the right way, start at our JSF wiki page and order an authoritative book.
See also:
Java / Jakarta EE web development, where do I start and what skills do I need?
What is the need of JSF, when UI can be achieved with JavaScript libraries such as jQuery and AngularJS

Localization problems on JSF. Redirects wrong address [duplicate]

I am unable to set a default page that loads in the browser when I start a Java EE project using Tomcat 8.0 from Eclipse.
I am trying to learn JSF, so I followed this tutorial
Everything works fine, but I can only see the created pages when I right click on the login.xhtml or welcome.xhtml file and choose "Run As/Run on Server".
So far, all the other web applications I have created loaded default page when I started the entire project. The default behavior is to load index.html page (or maybe index.jsp if there is some). So I added index.html and index.xhtml pages into my WEB-INF folder in the project, hoping that at least one of them will be shown. However, nothing happens. The browser always shows just the page on localhost:8080/JSFFaceletsTutorial/ URL, but the page is white clean, not even an error message. I think I have been getting error 404 in the process of solving this issue along the way, however, I am no longer able to reproduce this error and I don't remember what caused it.
I found that it's possible to change the default starting page
However, it doesn't work for me either. Regardless if I edit the web.xml file or not, I am getting the same result.
What is even more puzzling, is that when I tried to change the web browser: "Window/Web Browser/..." it acted for a while differently in the external web browsers than in the internal Eclipse web browser. The internal had always blank page - but the external web browsers once managed to show the index.html page - but it was some outdated version. Despite I made absolutely sure that I edited it, saved the changes, restarted the server... and still, it showed me the outdated version of the page.
And even in this case, it still ignored the changes made in the web.xml file.
But when I am trying it now, it again shows blank white page in all browsers. I am not aware of any change I made except for editing web.xml file...
My guess is that the problem is in the JSF technology I don't fully grasp yet. It's because when I choose to run the login.xhtml and welcome.xhtml pages using right click "Run As/Run on Server", the URL of those pages are on localhost:8080: with path /JSFFaceletsTutorial/faces/login.xhtml and /JSFFaceletsTutorial/faces/welcome.xhtml. That is weird, because I don't have any directory "faces" in my project.
Typing all possible permutations of:
<welcome-file-list>
<welcome-file>faces/index.html</welcome-file>
<welcome-file>faces/index.xhtm</welcome-file>
</welcome-file-list>
in the web.xml didn't help either. It didn't help when I typed the full address there either.
Here are warnings I am getting in the console (I skipped the INFO log entries):
"Dec 19, 2014 9:39:55 AM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'source' to 'org.eclipse.jst.jee.server:JSFFaceletsTutorial' did not find a matching property.
...
WARNING: JSF1074: Managed bean named 'loginBean' has already been registered. Replacing existing managed bean class type com.tutorial.LoginBean with com.tutorial.LoginBean.
Dec 19, 2014 9:39:57 AM org.apache.coyote.AbstractProtocol start"
I am not sure this is helpful though.
I am out of ideas now.
First of all, the <welcome-file> does not represent the path to the "default home page". It represents the filename of the physical file contained in the folder which you'd like to serve up as default file when a folder like /, /foo/, /foo/bar/, etc is requested.
So, in JSF 2.x flavor, that would basically be:
<welcome-file-list>
<welcome-file>index.xhtml</welcome-file>
</welcome-file-list>
This way, if the enduser requests / and you have /index.xhtml, then it will be served. Or, if the enduser requests /foo and you have /foo/index.xhtml, then it will be served, etc. If there is no such file, then a 404 error will be returned.
Now, you appear to have mapped your FacesServlet on a prefix <url-pattern> of /faces/*. This is a leftover from JSF 1.0/1.1 ages and really not recommended these days. Perhaps you were reading an outdated tutorial targeted at JSF 1.x, or a poorly maintained tutorial which was originally written for JSF 1.x and then uncarefully updated for JSF 2.x instead of rewritten from scratch.
That tutorial did also not seem to have explained you some servlet basics. Namely, in order to get JSF components in the XHTML page to run and generate some HTML output, the FacesServlet has to be invoked when the XHTML page is being requested. When you request the XHTML page like so /index.xhtml, while the FacesServlet is being mapped on /faces/*, then it won't be invoked. The browser would then retrieve the raw unparsed JSF source code instead of the generated HTML output. You can see it by rightclick, View Source in webbrowser. You should have requested the page like so /faces/index.xhtml so that the FacesServlet can run and produce HTML output which the browser can understand and present.
That only doesn't go well together with welcome files. This totally explains why you get a "clean white" (blank) page when using index.xhtml as welcome file (some inferior webbrowsers like IE would confusingly prompt a download dialog because of missing/wrong content type on the response containing raw XHTML source code). The FacesServlet was simply not being invoked. Just get rid of the old fashioned /faces/* URL pattern and use the JSF 2.x minded *.xhtml URL pattern instead.
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
This way the welcome files should work and you can just open JSF pages by directly requesting its physical URL without hassling with virtual URLs. This was not possible in JSF 1.x because it would let the FacesServlet run in an infinite loop calling itself and cause a stack overflow.
See also:
JSF Facelets: Sometimes I see the URL is .jsf and sometimes .xhtml. Why?
Setting application URL on WAS server, where does /faces/ come from?
What is the difference between creating JSF pages with .jsp or .xhtml or .jsf extension
Why can web.xml welcome-file be located inside WEB-INF
How to use a sub-folder as web.xml welcome directory
As to those warnings, they are unrelated but quite googlable.
i think this will work
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.xyz.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.xyz.org/xml/ns/javaee/web-app_3_1.xsd" id="WebApp_ID" version="3.1">
<welcome-file-list>
<welcome-file>/main/login.xhtml</welcome-file>
</welcome-file-list>
<!-- <servlet>
<servlet-name>login</servlet-name>
<servlet-class>com.xyz.servlets.login</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>login</servlet-name>
<url-pattern>/login</url-pattern>
</servlet-mapping> -->
</web-app>
You can set a default page in the web.xml file to have the facesServlet invoked in JSF in 2 ways:
<web-app xmlns="http://xmlns.xyz.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.xyz.org/xml/ns/javaee http://xmlns.xyz.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.xhtml</welcome-file>
</welcome-file-list>
</web-app>
or invoke the facesServlet directly from the welcome file like this:
<web-app xmlns="http://xmlns.xyz.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.xyz.org/xml/ns/javaee http://xmlns.xyz.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
<welcome-file-list>
<welcome-file>faces/index.xhtml</welcome-file>
</welcome-file-list>
</web-app>
I hope it helps somebody!

Prevent user going to pages through address bar

I have a web application. After user login, I want the user to navigate pages by clicking on buttons or links instead of manually changing the url on the browser address bar. I saw a few posts we can use security constraint to do so. I have this in the web.xml. But seems like it does not work.
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<security-constraint>
<display-name>Restrict raw XHTML Documents</display-name>
<web-resource-collection>
<web-resource-name>XHTML</web-resource-name>
<url-pattern>/faces/*</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
I really do not like this approach. There are a few things which user expect when using a web application and for the best user experience you should not try and change the way, users use the browser.
However, if you really want this, one of the following could be done:
You could instrument all of your links and intercept the click from javascript. When clicked, the interceptor should create a cookie which contains the path that the link was referring to. When the user requests a page, you should check if their cookie contains the requested url, otherwise redirect them to homepage.
You could generate a token for each url, and append it to the end of the url, so http://blabla.com/mypage would become http://blabla.com/mypage?token=298347287.
The token would incorporate information about the url and would have a timeout, after which it is no longer valid. Then you would check the validity of the token, which would verify that the user indeed clicked on the link, not just entered the url (note: it still could happen that the user enters the url containing the token by copying it from the link).

Changing welcome file location results in deployment failure

I am getting below error.
FAIL - Application at context path /sampleJSF could not be started
I want to change my welcome file location. I have a index.jsp page at WEB-INF/pages/index.jsp. How can I modify servlet mapping and welcome file list to achive this?
Here is my servlet-mapping and welcome-file-list from web.xml.
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>WEB-INF/*</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>WEB-INF/pages/index.jsp</welcome-file>
</welcome-file-list>
It look like that you misunderstood the purpose of both the welcome file setting and the /WEB-INF folder.
The welcome file must represent the name of the file which the server should serve from the current folder when a folder is been requested instead of a file in URL. E.g. /, /foo/, /bar/, etc. So, when you set it to index.jsp, then it will serve /index.jsp when / is requested, and /foo/index.jsp when /foo/ is requested, etc.
The /WEB-INF folder is for files which shouldn't be independently publicly accessible. For example, include files, template files, error files, tag files, configuration files, etcetera. Mapping the Faces Servlet on /WEB-INF makes no utter sense as the servlet container already restricts direct (public) access to /WEB-INF folder when the enduser purposefully enters the /WEB-INF folder in the URL.
Undo all those changes you made on the sample web application. They make simply no sense. Whatever functional requirement you had in mind for which you incorrectly thought that this is the right solution must be solved differently.
Unrelated to the concrete problem, it look like that you're just getting started with JSF, but do you know that JSP is deprecated since JSF 2.0 in 2009? Are you absolutely positive that you're learning JSF based on the right and up to date resources? I strongly recommend to do so, or you will end up having confusion headache and code disaster. Start at our JSF wiki page.

Avoid direct access to source code of JSF page

When I request /personal/faces/public/login.xhtml, then it works fine, but when I request /personal/public/login.xhtml without /faces I obtain the raw source code of the page.
I would like to avoid that people could see the source code of the page. How can I achieve this?
This is happening because you've specified /faces/* in your FacesServlet configuration in the web.xml. As a result, any file requested that does not match the specified url pattern will be served as a regular file with a GET request
Change that config to the following to ensure all JSF related requests go through the FacesServlet:
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
This ensures all files with .xhtml extension will be processed before returning to the client.
While the above solution may solve the immediate problem, what you're experiencing points to a deeper security issue. It indicates that anyone with a browser can request and download artifacts from your web application deployment and possibly other parts of your filesystem. This is a security hole you will need to look into. The options vary depending on your App server

Resources