Using Class Method in JSTL

[Steve Dyke]

I have bee trying to rewrite some of my classes to match patterns suggested on this forum.
Now I have an issue with legacy JSTL code I have previously.

This is my class:

public class LogOn extends AbstractLogon {
	
	private final LogOnParms logOnParms;
				
	public LogOn(LogOnParms logOnParms){
				
		this.logOnParms = logOnParms;
				
	}
	
	public User getUserObject(){
		
		if(this.logOnParms.getLogontype().equals("Guest")){
			
			return new User();
			
		}
		else{
			
			LogonValidation logOnValidation = new LogonValidation(this.logOnParms);
						
			this.logOnParms.setiNavigationMenuSource(logOnValidation.getNavigationMenuSource());
			this.logOnParms.setLogOnValidation(logOnValidation.getLogOnValidation());
			this.logOnParms.setLogOnValidation_override_msg(logOnValidation.getLogOnValidation_override_msg());
			
			return logOnValidation.getUser();
			
		}
			
	}
	
	public int iNavigationMenuSource(){
		
		return this.logOnParms.getiNavigationMenuSource();
		
	}
	
}

This is my legacy JSTL. Used over 1000 times in my JSP

<c:when test="${logonObj.userObject.XXX == ''XX'}">

[Tim Moores]

What is the issue you're having?

[Steve Dyke]

Tim Moores wrote:What is the issue you're having?

I realize now that JSTL will treat methods just like properties.

However, I think I have a bigger issue. In my class I posted earlier I am using the getUserObject method to define a User object
and use properties of the user object in the rest of my app.

But if I then use logOn.getObject().userid for example in other places in my code it will create another User object.

Do I set the public User getUserObject() to final?

[Paul Clapham]

Steve Dyke wrote:But if I then use logOn.getObject().userid for example in other places in my code it will create another User object.

Is that a problem? If so, why?

Do I set the public User getUserObject() to final?

If you want subclasses of LogOn to be unable to extend the getUserObject() method, then yes. But that question comes out of nowhere and I don't understand what problem you intend to fix with it.

[Tim Holloway]

Not to rain on the parade, but JSTL is just one step away from scriptlets, and scriptlets make the Bear growl.

More tellingly, this looks like a user-designed login/security system. The technical name for user-designed security is "hacked" or "pwned".

JEE provides a very secure container-managed authentication and authorization system along with a security API. In almost all cases, it's what I recommend for managing security.

Unless your job and training is full-time security, there's almost certainly going to be gaping loopholes in anything you design, and by "you design" I also mean the "resident genius" of most corporate shops.

In fact, about 90% of the user-designed systems I've seen could be bypassed by non-technical people in under 15 minutes.

Even professionally-designed security systems often fail, although as far as I know, no one has broken through JEE container security.

And one of the biggest advantages of JEE standard security is that many attacks get repulsed by the container itself, and never get near any vulnerable application code. You can't exploit holes if you can't even reach the holes.