Stripes

SSL support for Link, Url and Form Tag

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: Release 1.4, Release 1.5
  • Fix Version/s: Release 1.6
  • Component/s: Tag Library
  • Labels:
    None

Description

As a Struts user that learned about Stripes just a few days ago, I really missed something like the SSL-Extension for Struts.

In essence, it is now possible to mark an ActionBean as secure using a new annotation @Secure.
The Stripes tags used for urls, links and forms will check the security state of the destination ActionBean and automatically rewrite the target URL accordingly.
The configuration of the SSL settings (host, port) is done using init-parameters on the StripesFilter.

I have attached a ZIP file containing the modified/added java sources and the modified TLD file.
The sources also contain a second modification: I've also added a new attribute to the link and url tag called excludeSpecialParams. If this attribute is set to true, Stripes specific parameters (i.e. the source page parameter) is omitted from the final URL. However, keep in mind that removing those parameters can break your application.

My modifications are based on the 1.4 Beta 1 sources. A detailed explanation on what I have changed is included within the attached ZIP file.

Attachments

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Christian Schwanke added a comment - 12/Aug/06 2:26 PM

The modified sources

Show
Christian Schwanke added a comment - 12/Aug/06 2:26 PM The modified sources
Hide
Permalink
Christian Schwanke added a comment - 14/Aug/06 1:27 AM

Maybe the RedirectResolution should be "SSL-Aware" as well ? It would require to refactor the SSL rewriting code into an external class available to both the StripesTagSupport as well as the Resolution class. But it would provide more consistency and prevent the loading of SSL protected action beans through internally triggered redirects.

Show
Christian Schwanke added a comment - 14/Aug/06 1:27 AM Maybe the RedirectResolution should be "SSL-Aware" as well ? It would require to refactor the SSL rewriting code into an external class available to both the StripesTagSupport as well as the Resolution class. But it would provide more consistency and prevent the loading of SSL protected action beans through internally triggered redirects.
Hide
Permalink
Christian Schwanke added a comment - 14/Aug/06 2:31 AM

Version 2 - I've fixed a bug in UrlParser

Show
Christian Schwanke added a comment - 14/Aug/06 2:31 AM Version 2 - I've fixed a bug in UrlParser
Hide
Permalink
Christian Schwanke added a comment - 21/Aug/06 2:26 AM

Fixed an issue when using ssl within a context

Show
Christian Schwanke added a comment - 21/Aug/06 2:26 AM Fixed an issue when using ssl within a context
Hide
Permalink
Christian Schwanke added a comment - 24/Aug/06 4:29 AM

I've modified the RedirectResolution so that redirects also honor the ssl/non-ssl state of the destination actionbeans.
Since I needed the rewriting code in the RedirectResolution as well, I moved the main url-rewriting code from the StripesTagSupport to a new class SslUtil in the utils package (which also reduces the impact on the existing classes).

Show
Christian Schwanke added a comment - 24/Aug/06 4:29 AM I've modified the RedirectResolution so that redirects also honor the ssl/non-ssl state of the destination actionbeans. Since I needed the rewriting code in the RedirectResolution as well, I moved the main url-rewriting code from the StripesTagSupport to a new class SslUtil in the utils package (which also reduces the impact on the existing classes).
Hide
Permalink
Christian Schwanke added a comment - 21/Sep/06 5:24 AM

I've updated the SSL patch once again
Changes:

  • merged with the 1.4 Final sources
  • made the SSL configuration pluggable. this allows (for example) configuring SSL via JNDI, Spring or whatever
    (in case the SSL settings differ on different environments).
  • moved the SSL related utility classes into a new package (util/ssl)

I hope I haven't missed anything out.

Show
Christian Schwanke added a comment - 21/Sep/06 5:24 AM I've updated the SSL patch once again Changes:
  • merged with the 1.4 Final sources
  • made the SSL configuration pluggable. this allows (for example) configuring SSL via JNDI, Spring or whatever (in case the SSL settings differ on different environments).
  • moved the SSL related utility classes into a new package (util/ssl)
I hope I haven't missed anything out.
Hide
Permalink
Tim Fennell added a comment - 31/Jan/08 12:44 PM

Punting to 1.6 because a) we really want to get 1.5 out and this is the last thing holding it up and b) there just doesn't seem to be enough demand for this to hold up the release. We'll look at getting it done early in the 1.6 cycle, and hopefully 1.6 will only be a few months behind 1.5.

Show
Tim Fennell added a comment - 31/Jan/08 12:44 PM Punting to 1.6 because a) we really want to get 1.5 out and this is the last thing holding it up and b) there just doesn't seem to be enough demand for this to hold up the release. We'll look at getting it done early in the 1.6 cycle, and hopefully 1.6 will only be a few months behind 1.5.
Hide
Permalink
Christian Schwanke added a comment - 31/Jan/08 5:48 PM

That's fine with me since I'm also very interested in using 1.5.
I'm not sure wether the SSL part should be part of the core stripes - especially since the demand seems to be not that high. Maybe some kind of plugin mechanism is better suited. On the other: when not used, the ssl modifications should not have any impact.

Show
Christian Schwanke added a comment - 31/Jan/08 5:48 PM That's fine with me since I'm also very interested in using 1.5. I'm not sure wether the SSL part should be part of the core stripes - especially since the demand seems to be not that high. Maybe some kind of plugin mechanism is better suited. On the other: when not used, the ssl modifications should not have any impact.
Hide
Permalink
Tim Fennell added a comment - 31/Jan/08 5:58 PM

I do think it's a good thing to be in the core! Just that we don't have the time to do it if we want to get 1.5 out asap.

Show
Tim Fennell added a comment - 31/Jan/08 5:58 PM I do think it's a good thing to be in the core! Just that we don't have the time to do it if we want to get 1.5 out asap.
Hide
Permalink
Iwao AVE! added a comment - 04/Jul/08 9:26 AM

Christian,

I needed this feature recently and your patch saved me. Many thanks!

A few comments:

  • I think you forgot to add RuntimeConfiguration.java to the v5 archive.
  • The name of the annotation @Secure might be too common, I renamed it to @Ssl locally.
  • An action bean that handles ajax requests should not change the protocol to satisfy 'same origin policy'.
    I have added a parameter 'RewritePolicy' to the annotation.
    There are three possible values for the parameter:
    (1) SECURE : Always use https. Default.
    (2) UNSECURE : Never use https; i.e. always use http. Same behavior as if the annotation were not present.
    (3) NO_REWRITE : Leave the protocol as it is (just use relative path).
Show
Iwao AVE! added a comment - 04/Jul/08 9:26 AM Christian, I needed this feature recently and your patch saved me. Many thanks! A few comments:
  • I think you forgot to add RuntimeConfiguration.java to the v5 archive.
  • The name of the annotation @Secure might be too common, I renamed it to @Ssl locally.
  • An action bean that handles ajax requests should not change the protocol to satisfy 'same origin policy'. I have added a parameter 'RewritePolicy' to the annotation. There are three possible values for the parameter: (1) SECURE : Always use https. Default. (2) UNSECURE : Never use https; i.e. always use http. Same behavior as if the annotation were not present. (3) NO_REWRITE : Leave the protocol as it is (just use relative path).
Hide
Permalink
Christian Schwanke added a comment - 07/Jul/08 4:26 PM

I'm glad my patch helped you. You are right, I forgot the RuntimeConfiguration in the v5-Archive - sorry about that. I also agree with your other enhancements – I'll update the patch to the 1.5 sources and include your fixes as well. I hope I'll find the time this week to update this ticket with a new version.

Show
Christian Schwanke added a comment - 07/Jul/08 4:26 PM I'm glad my patch helped you. You are right, I forgot the RuntimeConfiguration in the v5-Archive - sorry about that. I also agree with your other enhancements – I'll update the patch to the 1.5 sources and include your fixes as well. I hope I'll find the time this week to update this ticket with a new version.
Hide
Permalink
Iwao AVE! added a comment - 09/Jul/08 9:55 AM

I actually ported the patch to recent trunk version, but I haven't had enough time for cleaning it up...
The way of handling context path had been changed since 1.4 and I think my modification to the SslUtil class needs re-factoring.

–
FYI, there was a feedback from Alan Burlison about the terminology.
He suggested that the word 'unsecure' should be replaced with 'insecure'.

Show
Iwao AVE! added a comment - 09/Jul/08 9:55 AM I actually ported the patch to recent trunk version, but I haven't had enough time for cleaning it up... The way of handling context path had been changed since 1.4 and I think my modification to the SslUtil class needs re-factoring. – FYI, there was a feedback from Alan Burlison about the terminology. He suggested that the word 'unsecure' should be replaced with 'insecure'.
Hide
Permalink
Christian Schwanke added a comment - 09/Jul/08 11:26 AM

Hi,
I took a shot at it yesterday but I haven't got around to test my newest modifications.
I added the possibility to annotate event handlers instead of whole actionbeans - it is now possible to annotate an actionbean as being secure and override this setting on an event handler in that actionbean - this should be useful for handler methods serving ajax request. This is how it would look like:

@Ssl
public class SecureActionBean implements ActionBean {

@Ssl(enabled=false) // turn off SSL for this handler
@DefaultHandler
public Resolution showForm() { ... }

@HandlesEvent("submit")
public Resolution handleSubmit() { ... // this handler is secured since it inherits the actionbean's annotation }
}

And I added an attribute that allows you to specify the session-Id handling per annotation.
Anyways, as I said, the implementation is done but I haven't got around to testing. I'll post a new patch as soon as I manage to test the new stuff a little bit

Show
Christian Schwanke added a comment - 09/Jul/08 11:26 AM Hi, I took a shot at it yesterday but I haven't got around to test my newest modifications. I added the possibility to annotate event handlers instead of whole actionbeans - it is now possible to annotate an actionbean as being secure and override this setting on an event handler in that actionbean - this should be useful for handler methods serving ajax request. This is how it would look like: @Ssl public class SecureActionBean implements ActionBean { @Ssl(enabled=false) // turn off SSL for this handler @DefaultHandler public Resolution showForm() { ... } @HandlesEvent("submit") public Resolution handleSubmit() { ... // this handler is secured since it inherits the actionbean's annotation } } And I added an attribute that allows you to specify the session-Id handling per annotation. Anyways, as I said, the implementation is done but I haven't got around to testing. I'll post a new patch as soon as I manage to test the new stuff a little bit
Hide
Permalink
Adam Stokar added a comment - 05/Nov/10 11:14 AM

Hi,

What is the status on getting this functionality into the core version? I think any application that has a "My Account" page or something similar where a user is managing their payment options, password, etc., can make use of this. You don't want all the pages in the app to be secure, just the configuration pages. I used a hack in Struts but have moved to Stripes and am hoping to have an easy way to do this in the core.

Thanks,

Adam

Show
Adam Stokar added a comment - 05/Nov/10 11:14 AM Hi, What is the status on getting this functionality into the core version? I think any application that has a "My Account" page or something similar where a user is managing their payment options, password, etc., can make use of this. You don't want all the pages in the app to be secure, just the configuration pages. I used a hack in Struts but have moved to Stripes and am hoping to have an easy way to do this in the core. Thanks, Adam

People

Vote (10)
Watch (5)

Dates

  • Created:
    12/Aug/06 2:26 PM
    Updated:
    05/Nov/10 11:14 AM
Atlassian JIRA (v4.2#587) | Report a problem
Powered by a free Atlassian JIRA open source license for Stripes Framework. Try JIRA - bug tracking software for your team.