Saskia de Jong

Originally posted by Gregg Bolinger:


There is nothing special about JSF once it's on the browser. At that point it's all HTML and it still uses the HTTP protocal to handle requests and responses. If you are looking for vulnerabilities, look for them in HTTP, not the framework used.

I don't agree with you.

There is a special vulnerability in the JSF and that's the fact that view state can (optionally) be saved to the client. JSF 1.1 does not define a method to encrypt this data, so theoretically you could decode this state (which appears as a long base64 encoded string in the HTML you receive from the server), manipulate it, and send it back.

If you take a look at the source code of MyFaces for example, you'll notive that the restore state in all components does not apply any checks at all. On the one hand, data that is restored into JSF components this way is the same data a user can enter through the (input) components directly, and in a good design this data is checked in business logic that comes after the view anyway.

On the other hand, converters and validators themselves can also be parameterized (e.g. in the faces-config file) and these ALSO use the view state/restore mechanism. Typically, you don't check whether the parameters a validator receives from the state restore are the same ones it initially received. (you might be able to do this with some static variables, but I've never seen anyone actually take this path)

I'm not really sure what the point is of saving/restoring converter/validator parameters that are defined in faces-config.xml. They are constants and never change. When doing a non-faces request, JSF configs your converter/validator with these values, but for a faces request JSF uses the values from the view state (which, as I mentioned earlier can be manipulated by the user).

The problem with the view state when saved on the client has been recognized by Sun, as JSF 1.2 contains an encryption for this state in the spec. (disclaimer: I haven't read the JSF 1.2 spec yet, but this is what I understood of JSF 1.2).

That a non-reply. I don't the OP is interested in yet another demo of something, but instead is looking for some REAL production site used by REAL users.

One such site that comes to mind is: https://www.neteller.com/
This one was build on MyFaces. There are probably many more, but a list would indeed be nice.

Recently I was transferred to a new project where I got an assignment to do some JSF stuff. After I checked in my code, I got a furious message from the project leader who told me HTML tags don't belong in JSF (when using it in a JSP file).

I'm not talking about making complex layouts by abusing tables, but just some rather innocent br tags between the JSF tags, e.g:

<h :-o utputText value="something" /> <br> <h :-o utputText value="somethingElse" /> <br><br> <h:commandLink action="doFoo">

According to him, my JSF tree isn't 100% components anymore and styling should only be done through CSS in which br tags (among others) don't have any place. Now I'm rather confused. He sounds pretty convincing, but actually I don't see a lot of evidence on the net that shares this opinion. To the contrary, spec lead Ed Burns even uses the HTML table tag in his own examples and many textbooks use HTML mixed with JSF tags as well.

So I wonder how people out here think about this...

Originally posted by Jeff Albertson:
If you want a button to *conditionally* open a window,

Isn't that story a bit offtopic? I thought this thread was about a browser showing the wrong URL when using JSF's navigation rules?

<redirect/> is sadly not always an option. The problem is you LOOSE al values that have been set in your request scope beans during for example the process updates phase.

Using <redirect/> forces you in a lot of situations to use session scoped beans. However session beans have their own problems, namely the fact that a user can't have different versions of the same page open and expect a submit to yield sane results.

In a typical scenario where page A forwards to B and B can forward back to A, you're in the curious situation that the browser shows A when you're actually on B and B when you're actually on A, except for the first time you're on A. In general, the browser always shows the previous page visitted instead of the current one.

Doesn't anyone have a solution to this?

I would say that showing ONE SINGLE url for a set of pages that forward to eachother is way better than showing the WRONG page. Showing the wrong page is very confusing for users, let alone a true support nightmare.

I've been trying to play a bit with a custom NavigationHandler and setting the action on the generated forms of a JSF page directly to a single page, but thusfar I haven't come really far with this. Since this is such a general problem I almost can't believe someone else hasn't come up with a solution before.

Ok, thanks for the quick reply Jim!

On page 115 of k&b SCJP 5 the following is stated (I quote freely):

"[Take] a class that declares it implements an interface [...] but doesn't implement the methods [...] if any [super] class has provided method implementations AND has declared that it implements the interface, then [this] subclass is under no obligation to re-implement those methods"

Technically this is correct. However, I think putting it this way is slightly misleading. The reader might think the superclass HAS to declare the interface too, but this does not need to happen at all.

As an example, the following code compiles with no errors:

package package3; public class SuperClass { public void foo() { } }


package package3; public interface FooInterface { public void foo(); }

package package3; public class SubClass extends SuperClass implements FooInterface { }

The class "SubClass" uses the inherited method foo() to implement the FooInterface, without any declaration of the FooInterface within the class that defines this method. Of course the code still compiles if "SuperClass" had indeed declared the interface, but as the example shows this is not required at all.

It seems to me that it might actually be more accurate if the k&b book mentions that the AND part in the mentioned quote is just an optional thing. Currently it really sounds (at least to me) as a requirement.

Originally posted by marc weber:

That's my interpretation. I tried to get an overflow with a tangled web of constructors going around in circles calling each other, but the compiler was "smart enough" to catch it.

[ February 24, 2006: Message edited by: marc weber ]

Maybe I'm overlooking something but it seems to me that the compiler doesn't have to be particular smart to catch this error. I.e. it just needs to find atleast 1 ctor in which there is either an explicit super call or in which a super call can be inserted. No need to follow a web, just check and check off each ctor for super() appearances. If the count is 0 after looking at each ctor there must be some recursion going on.

Anyway, I would appreciate it if Bert could respond to this issue. The way he writes about it makes it look like this is a compiler implementation dependent case, but if the Java spec actually requires this to be a compilaton error we're talking about something entirely else.

(btw, I just checked with JDT from Eclipse 3.1 and it also gives the "Recursive Contructor Innovation" message.)

If its really urgent you may want to try the following hack. It's mean and ugly and won't work on any other JSF implementation that you test it on. Anyway, just before your DB operaton get a hold of the current stack trace (use the std java API for that). Find out who's calling your function, and skip or peform the DB operation depending on the outcome.

Of course, this is not the real solution to this problem.

Maybe it would also be possible to query the facescontext about the current fase? That would be a little less hacky. You could perform the DB operation then only in a specific fase.

I see. Thanks a lot Bert!

For other people who are interested in this matter, this is what the spec exactly says in 8.4:

public void add<EventListenerType>(<EventListenerType> a) public void remove<EventListenerType>(<EventListenerType> a)

where both methods take the same �<EventListenerType>� type argument, where the �<EventListenerType>� type extends the �java.util.EventListener� interface, where the first method starts with �add�, the second method starts with �remove�, and where the �<EventListenerType>� type name ends with �Listener�.

(emphasis added by me)
[ February 11, 2006: Message edited by: Saskia de Jong ]

Originally posted by Bert Bates:

Thanks for your help,
Bert

You're welcome. At least thanks for the quick reply and for clearing this up

Btw, another question that I have doubts about is 1.5. It asks for valid method names according to the Javabeans standard. The answer is that 'addSize' is not correct, since 'add' is not a standard name prefix. However, 'add' certainly is a standard prefix for event listener registration.

Both the Javabean spec (section 6.5 page 29) and your book (page 9) says "add" + eventlistener type:

public void add<ListenerType>(<ListenerType> listener);

Now I'll agree that Size would be a strange name for an eventlistener, but I haven't seen it written anywhere that there's also a naming rule for the listener type itself. Specifically, your book makes no mention of the fact that the type names MUST end with "Listener". Therefore, when taking the self test one must assume "addSize" is a valid name.

Could you also clearify this issue?

I'm sorry if this has been reported before or that I've overlooked something, but the answer to self test 1.2 in the K&B SJCP 5 book seems wrong to me.

The questions asks for compilable code. Answer B is given as:

public abstract class Canine { public Bark speak() { } }

The book says answer B is a correct answer, but unless {} is to be read as "any legal implementation", this answer is wrong. The code can't compile since there's nothing being returned.

The following would surely compile:
public abstract class Canine { public Bark speak() { return null;} }

The following would compile if Bark had a public no-arg ctor (but we don't know):
public abstract class Canine { public Bark speak() { return new Bark();} }

But the code as given does absolutely not compile. Did I just miss the definition of {} for quesions somewhere?

Originally posted by Alexander Jesse:

I would say here is your problem...

JSF is not made to listen to such URL-parameters.

I wonder. Is that just his problem or does it reflect a problem with JSF in general? Like it or not, JSF applications are not deployed in isolation. Other pages on the web need to be able to link to JSF pages and they need to do so while providing parameters.

This is not a workaround, but the only correct way to do it...

I haven't tried this, but just a wild idea. You might use a binding on your <h:form> element to your backing bean( <h:form binding="testEdit.bind" /> ). The setBind method you specify here will be called at each page load, giving you the opportunity to act on this 'event'. In your binding funcion, you could check whether the mentioned GET parameters has been supplied. If it has, simply use the UIComponent that is handed to you to locate the component with ID attrib. Upon reaching this component, try to set its value to null.

I have no idea whether the binding method is called in time to reset the error state, but it might just work. I used this technique in the past to dynamically apply effects to components in my tree (e.g. changing the css attribute).

Could you post back whether this worked or not?

Yet another trick is to create a binding to a backing bean.

<h:form binding="#{backingbean.init}" > ... rest of code here

setInit() will now get called at each page load. I think this is a little less of a hack than the hidden input is. (caveat you MUST also supply the getter for init even though it won't be used)

I'm also not really sure if I agree with the comment given above that page loads are something you don't want to think about. Maybe you don't want to think about them as explicit page loads, but you do want some notion of a pre-render event for the whole interface. ASP.NET looks very much like JSF and it does have this concept.

Also, if you're dealing with session scoped backing beans and need to process get parameters then there's no other way. You need some onPageLoad mechanism. Now some people would say get parameters don't belong in a JSF application. The matter of the fact is however that people wish to link to pages from external sources and when that happens there's just no way around using get parameters.

Originally posted by Sergey Smirnov:
Why do you try /jsftest2.jsf, but not /jsftest2.jsp ?

Since jsftest2.jsp is a file containing JSF tags. If I use the name jsftest2.jsp in the include tag, then it's not going through the JSF servlet. In my setup *.jsf files are mapped to the JSF servlet.

Nevertheless I did try to use jsftest2.jsp, but then I just get a msg that JSF is not initialized.