Re: Redirect to HTTPS?
Resurrecting this thread from the dead :D disclaimer: I am very new to wicket and its philosophy, so I am making some points related to secure pages. I read about securing pages though ssl and made a comment there http://cwiki.apache.org/confluence/display/WICKET/How+to+switch+to+SSL+mode But I saw it too much unneeded coding, as servlet spec allows us to declare at web.xml the URLs to secure. At my application I can configure secure mount points, like /admin mountBookmarkablePage(/cad, Inicial.class); mountBookmarkablePage(/res, Resultado.class); mountBookmarkablePage(/admin/results, AdminResults.class); mountBookmarkablePage(/admin/users, AdminUsers.class); And declare the /admin as to be secured through SSL security-constraint display-namessl-test/display-name web-resource-collection web-resource-nameresultado/web-resource-name description/ url-pattern/admin/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodHEAD/http-method http-methodPUT/http-method http-methodOPTIONS/http-method http-methodTRACE/http-method http-methodDELETE/http-method /web-resource-collection user-data-constraint descriptionssl mode/description transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint I think its easier than doing all the code displayed before. And dismiss the application developer to know about server infrastructure (port and hostname) Eelco Hillenius wrote: All the other encode methods get the proper wicket URL but doesn't prepend the webapp URI which this final encode method does. Beyond filing a RFE to either make this method non-final or provide a postEncode(RequestCycle, IRequestTarget) method before URL encoding, we will have to copy the entire class and provide this behavior. Thoughts? I stand by my suggestion that you could just try to redirect to a secure page. After that, the relative URLs stay secure no? If I'm missing something, please tell. - Claudio Miranda http://weblogs.java.net/blog/claudio http://www.claudius.com.br/blog -- View this message in context: http://www.nabble.com/Redirect-to-HTTPS--tp12861028p15618826.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Dave, There is a difference in how items are displayed and how submits/links are to be performed. There are cases where a HTTP page has a form that is to be submitted via HTTPS. And furthermore, when an Page is to be displayed via HTTPS, not all items (images,resources) are to be served via HTTPS (ex: i.m.g src=/path/image.gif on a secure page will be accessed via HTTPS). Hopefully you agree with this. Let me explain via a use case, I think this would be more helpful. In the end, I will attempt to differentiate between the two approaches. Five pages for my application (to keep it simple): - home page - login page - user home page - user profile page - company info page. On the home page, I have login portlet/form (user id, password). Requirements: - home page is to be displayed via HTTP - Login form is to be submitted via HTTPS - Upon successful login, the user home page is displayed in HTTP - if login is unsuccessful, the login page is displayed in HTTPS On the user home page, there is a link to the user profile page. - user profile page is to be displayed via HTTPS - user profile submits are to be via HTTPS - canceling the user profile will send it back to the user home page via HTTP - All images and resource links are to be accessed via HTTP irregardless if the page itself is to be displayed in HTTP/HTTPS - Company info page is to be available at all times and is to be accessed via HTTP. Now I tried both approaches with the above scenarios and viewed the source of the generated html in the browser. Here are my observations. Please correct me if I mistaken as it is possible I have missed something or incorrect in my evaluation. In both approaches, LoginPage and UserProfile has @RequiredSSL. When accessed, they are displayed properly. The behaviors in your suggested approach are this: - I cannot have a login portlet on the home page submit the form via HTTPS unless the Home Page is in HTTPS - When on any secure page, the link to Company info page will first submit via HTTPS then redirect to HTTP (two network requests) - When on any secure page, all resources and images will be fetched via HTTPS In my suggested approach: - I can declare the Form @RequiredSSL and have its submit performed via HTTPS no matter if the form is on a non-secure page - All code generated resources and images will be accessed via HTTP no matter if page is displayed in HTTPS - no redirection is necessary when accessing a non-secure page from a secure page because the URL generatation is proactive Most of my clients do not want to have trivial resources (js, css, images) fetched via HTTPS. This creates an undo burden on the SSL pipe and ultimately affects performance, user experience, and capacity planning. While this is trivial for a 100 user site with 1 txn/sec, this will not scale well for 1000txn/sec site. I define txn as a http req in this case not business txn. Does this make sense to you? Have I cleared up a little? or have clouded it further? Cheers - Doug -- View this message in context: http://www.nabble.com/Redirect-to-HTTPS--tf4509537.html#a12906996 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Hi, Doug. Most of my clients do not want to have trivial resources (js, css, images) fetched via HTTPS. This creates an undo burden on the SSL pipe and ultimately affects performance, user experience, and capacity planning. While this is trivial for a 100 user site with 1 txn/sec, this will not scale well for 1000txn/sec site. I define txn as a http req in this case not business txn. Hmmm... well, if it's a customer demand, then I guess you have no choice. I understand that you want to lessen the burden on the server, since ssl/tls causes a lot of overhead... Maybe if I were in your shoes, I'd do the same, I don't know. But, I'm not in your shoes. ;-) To me it seems really complicated for negligible benefit to mix up http with https. In other words... There is a difference in how items are displayed and how submits/links are to be performed. There are cases where a HTTP page has a form that is to be submitted via HTTPS. And furthermore, when an Page is to be displayed via HTTPS, not all items (images,resources) are to be served via HTTPS (ex: i.m.g src=/path/image.gif on a secure page will be accessed via HTTPS). Hopefully you agree with this. ... I guess I don't agree with this. Wouldn't it just be easier to invest a little more in hardware? Anyway, you know your needs better than I do. I'm just suggesting that you think about this once more before jumping into something that doesn't seem right (to me). Also, by mixing non-secured information with a secure transaction, I think you're creating an unnecessary vulnerability. - All images and resource links are to be accessed via HTTP irregardless if the page itself is to be displayed in HTTP/HTTPS - Company info page is to be available at all times and is to be accessed via HTTP. Sure, perfectly reasonable to have the company page in the clear. What I'm suggesting is that you don't mix http with https in the same page. In these cases, you should just be able to use ExternalLink without requiring any hacks to your code. The behaviors in your suggested approach are this: - I cannot have a login portlet on the home page submit the form via HTTPS unless the Home Page is in HTTPS Yep, that's what I'm saying. ;-) You could always provide a link to a secure login page. - When on any secure page, the link to Company info page will first submit via HTTPS then redirect to HTTP (two network requests) Why? If you use ExternalLink, you can link directory to http://companypage - When on any secure page, all resources and images will be fetched via HTTPS Yep. I think that's the correct way. Does this make sense to you? Have I cleared up a little? or have clouded it further? No, it's very clear. I guess we just have different ways of thinking. Please let me know how it works out for you. I'm interested. Good luck! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
On 26 Sep 2007, at 12:26, Doug Leeper wrote: - All images and resource links are to be accessed via HTTP irregardless if the page itself is to be displayed in HTTP/HTTPS Most browsers will complain when non-secure elements are included on a secured page. This page contains both secure and nonsecure items tends to worry users.
RE: Redirect to HTTPS?
Use a keep-alive SSL connection. This amortizes the SSL handshake cost over the entire page (or more). If the keep alive is long enough, say 1-5 mins, then common ajax should be included in there as well. The other thing to do is to ask for off screen downloads of cached css/images in the login page. Off screen in this case can be style=hidden pieces. Do the smaller ones first on the page to keep the connections down. tim -Original Message- From: David Leangen [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 5:17 PM To: users@wicket.apache.org Subject: Re: Redirect to HTTPS? Hi, Doug. Most of my clients do not want to have trivial resources (js, css, images) fetched via HTTPS. This creates an undo burden on the SSL pipe and ultimately affects performance, user experience, and capacity planning. While this is trivial for a 100 user site with 1 txn/sec, this will not scale well for 1000txn/sec site. I define txn as a http req in this case not business txn. Hmmm... well, if it's a customer demand, then I guess you have no choice. I understand that you want to lessen the burden on the server, since ssl/tls causes a lot of overhead... Maybe if I were in your shoes, I'd do the same, I don't know. But, I'm not in your shoes. ;-) To me it seems really complicated for negligible benefit to mix up http with https. In other words... There is a difference in how items are displayed and how submits/links are to be performed. There are cases where a HTTP page has a form that is to be submitted via HTTPS. And furthermore, when an Page is to be displayed via HTTPS, not all items (images,resources) are to be served via HTTPS (ex: i.m.g src=/path/image.gif on a secure page will be accessed via HTTPS). Hopefully you agree with this. ... I guess I don't agree with this. Wouldn't it just be easier to invest a little more in hardware? Anyway, you know your needs better than I do. I'm just suggesting that you think about this once more before jumping into something that doesn't seem right (to me). Also, by mixing non-secured information with a secure transaction, I think you're creating an unnecessary vulnerability. - All images and resource links are to be accessed via HTTP irregardless if the page itself is to be displayed in HTTP/HTTPS - Company info page is to be available at all times and is to be accessed via HTTP. Sure, perfectly reasonable to have the company page in the clear. What I'm suggesting is that you don't mix http with https in the same page. In these cases, you should just be able to use ExternalLink without requiring any hacks to your code. The behaviors in your suggested approach are this: - I cannot have a login portlet on the home page submit the form via HTTPS unless the Home Page is in HTTPS Yep, that's what I'm saying. ;-) You could always provide a link to a secure login page. - When on any secure page, the link to Company info page will first submit via HTTPS then redirect to HTTP (two network requests) Why? If you use ExternalLink, you can link directory to http://companypage - When on any secure page, all resources and images will be fetched via HTTPS Yep. I think that's the correct way. Does this make sense to you? Have I cleared up a little? or have clouded it further? No, it's very clear. I guess we just have different ways of thinking. Please let me know how it works out for you. I'm interested. Good luck! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
I haven't tested but I think the solution is to override public final CharSequence encode(final RequestCycle requestCycle,final IRequestTarget requestTarget)BUT...it is final so we can't reuse the class directly but have to make a copy. And this is where your alarm bells should go off. Admittedly we have been very generous in using final, maybe sometimes a bit too much, but the idea behind it is that we think that what you want to do can probably be done in a better way, or we simply don't know (and an unrelated reason is self protection so that we have more options for refactoring without breaking the whole world). So, any time you come across a situation where something is final and you think you have a really good use case to get rid of it, you should post a message here. Chances are we can tell you a better way to do it, or you convince us to remove final or in some other way facilitate your use case. As for your case, I'd like to hear what Al thinks about this. It might work to make the factor prepending into a separate, overridable method. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Eelco Hillenius wrote: I stand by my suggestion that you could just try to redirect to a secure page. After that, the relative URLs stay secure no? If I'm missing something, please tell. Eelco I think we are both missing something. There are a couple of situations (aka requirements) that I want to describe and hopefully get your opinion on how to go about solving them. 1. A page has information that needs to be secure, i.e. demographic information, billing information. This information can be accessed from a non-secured page, i.e. home page I believe what you proposed can be accomplished. Not sure how though. A working example would do wonders here. I am still learning Wicket. 2. Submitting a form has to be secure, i.e. login information, demographics information This can be from a non-secure page (login home page) or secure-page (demogaphics page). Not sure how to do this without the proposed refactor (doPostPrepend()) since the URL generation is encapsulated and final. 3. When on a secure page, link to a non-secure page (from demographics page to company info) Wicket currently builds URLs that are relative to domain and agnostic to protocol (https/http), i.e. /?wicket=... What this does will do if redirect to a secure page is keep all subsequent links in the https mode. Therefore, this will place an undo amount of load on the https server and potentially slow down the user experience. The proposed refactor would mitigate 1 and 3. For 2, I foresee a SecureLink/SecureButton/SubmitLink (and others?) that would need to created which has the RequireSSL annotation. By doing so, it would fit nicely in the proposed refactor. Does this clear it up? These are actual client requirements and not sure how to proceed without the proposed solution. Thanks - Doug -- View this message in context: http://www.nabble.com/Redirect-to-HTTPS--tf4509537.html#a12878724 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
I have no problem with the approach in finals. I think you guys have done a great job. Please see my response http://www.nabble.com/Redirect-to-HTTPS--tf4509537.html#a12878724 here I, too, am very interested in the feedback on this. Eelco Hillenius wrote: I haven't tested but I think the solution is to override public final CharSequence encode(final RequestCycle requestCycle,final IRequestTarget requestTarget)BUT...it is final so we can't reuse the class directly but have to make a copy. And this is where your alarm bells should go off. Admittedly we have been very generous in using final, maybe sometimes a bit too much, but the idea behind it is that we think that what you want to do can probably be done in a better way, or we simply don't know (and an unrelated reason is self protection so that we have more options for refactoring without breaking the whole world). So, any time you come across a situation where something is final and you think you have a really good use case to get rid of it, you should post a message here. Chances are we can tell you a better way to do it, or you convince us to remove final or in some other way facilitate your use case. As for your case, I'd like to hear what Al thinks about this. It might work to make the factor prepending into a separate, overridable method. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Redirect-to-HTTPS--tf4509537.html#a12878787 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Thanks for your input guys, after some experimenting I used the annotation solution and got it working on 1.3 with some tweaking. I had to take out the IResponseStrategy and just override respond(..) in the RequestCycleProcessor instead. Also the redirection portion had to be rewritten as included below to get the paths right. I'll add my findings to the wiki page. --- redirect portion that has to be changed to get the paths right --- StringBuffer url = new StringBuffer(https://;); url.append(httpServletRequest.getServerName()); url.append(: + MyWebApplication.get().getHttpsPort()); url.append(webRequest.getHttpServletRequest().getContextPath()); url.append(webRequest.getServletPath()); webResponse.redirect(url.toString()); --- end of redirect portion --- // Daniel On 2007-09-25, at 08:00, Eelco Hillenius wrote: All the other encode methods get the proper wicket URL but doesn't prepend the webapp URI which this final encode method does. Beyond filing a RFE to either make this method non-final or provide a postEncode (RequestCycle, IRequestTarget) method before URL encoding, we will have to copy the entire class and provide this behavior. Thoughts? I stand by my suggestion that you could just try to redirect to a secure page. After that, the relative URLs stay secure no? If I'm missing something, please tell. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
I'm not as expert in cryptology, but many of the use cases you write below somehow don't seem right to me. 1. A page has information that needs to be secure, i.e. demographic information, billing information. This information can be accessed from a non-secured page, i.e. home page Is the page secured, or is it not? If you access secured information through a non-secured page, then the info is no longer secured. 2. Submitting a form has to be secure, i.e. login information, demographics information This can be from a non-secure page (login home page) or secure-page (demogaphics page). Not sure how to do this without the proposed refactor (doPostPrepend()) since the URL generation is encapsulated and final. Same thing. If you're submitting information via http, then it's no loner secured. You need to submit via https, with all the ssl/tls caveats in place, for it to be secured. 3. When on a secure page, link to a non-secure page (from demographics page to company info) Sure, that's not a problem. Just use an ExternalLink. What Eelco writes seems to make sense to me. I think you need to consider the http and https versions conceptually as two separate apps, or else you'll run into a lot of trouble. Cheers, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
just take whatever has been discussed on this list and strip it down to whatever level you need. i dont think any one is interesting in doing this for you... -igor On 9/24/07, Daniel Frisk [EMAIL PROTECTED] wrote: I'm trying to add a check to the constructor on one of our pages (a credit card processing page) which should: 1. If protocol is HTTPS; continue as usual 2. Else redirect so that HTTPS is used to access the same page I saw the sample in the wiki with the annotations that intercepted the request processing and etc but it seemed overly complicated for this tiny check, any ideas for a minimal implementation which could serve this purpose? // Daniel Frisk jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Well... Now that was certainly helpful. This was not intended as a do my homework question, read it as: I don't know Wicket inside out yet and could use a hint if someone gets an idea from reading my question. You wasn't that someone today and you didn't help with your post, you lose karma :-) // Daniel On 2007-09-24, at 19:00, Igor Vaynberg wrote: just take whatever has been discussed on this list and strip it down to whatever level you need. i dont think any one is interesting in doing this for you... -igor On 9/24/07, Daniel Frisk [EMAIL PROTECTED] wrote: I'm trying to add a check to the constructor on one of our pages (a credit card processing page) which should: 1. If protocol is HTTPS; continue as usual 2. Else redirect so that HTTPS is used to access the same page I saw the sample in the wiki with the annotations that intercepted the request processing and etc but it seemed overly complicated for this tiny check, any ideas for a minimal implementation which could serve this purpose? // Daniel Frisk jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
well, i dont know. you said you have seen a few solutions on this list but they are too complicated. you want something more stripped down. so why not strip it down yourself. sure sounds like do my homework for me. as far as karma, im already in the negative. -gior On 9/24/07, Daniel Frisk [EMAIL PROTECTED] wrote: Well... Now that was certainly helpful. This was not intended as a do my homework question, read it as: I don't know Wicket inside out yet and could use a hint if someone gets an idea from reading my question. You wasn't that someone today and you didn't help with your post, you lose karma :-) // Daniel On 2007-09-24, at 19:00, Igor Vaynberg wrote: just take whatever has been discussed on this list and strip it down to whatever level you need. i dont think any one is interesting in doing this for you... -igor On 9/24/07, Daniel Frisk [EMAIL PROTECTED] wrote: I'm trying to add a check to the constructor on one of our pages (a credit card processing page) which should: 1. If protocol is HTTPS; continue as usual 2. Else redirect so that HTTPS is used to access the same page I saw the sample in the wiki with the annotations that intercepted the request processing and etc but it seemed overly complicated for this tiny check, any ideas for a minimal implementation which could serve this purpose? // Daniel Frisk jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
On 9/24/07, Daniel Frisk [EMAIL PROTECTED] wrote: I'm trying to add a check to the constructor on one of our pages (a credit card processing page) which should: 1. If protocol is HTTPS; continue as usual 2. Else redirect so that HTTPS is used to access the same page I saw the sample in the wiki with the annotations that intercepted the request processing and etc but it seemed overly complicated for this tiny check, any ideas for a minimal implementation which could serve this purpose? The basic idea I think is here: StringBuffer url = new StringBuffer(https://; + httpServletRequest.getServerName()); url.append(: + MyApplication.get().getSslPort()); String q = RequestCycle.get().urlFor(requestTarget).toString(); url.append(q); webResponse.redirect(url.toString()); That pattern outlined in the WIKI article is a way to make it easy to build an application where you have to switch often. I haven't played around with these things, but if you want to do something relatively simple, and you don't want to have to configure the render strategy particularly for this, I think you should be able to just redirect e.g. using a refresh header or using the redirect page to a bookmarkable page. Would that help? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
Hi, In my previous project, it was done by configuring (rewrite rules) the http front-end (apache, lighttpd,...). It's an other solution, that avoid developper to deal certificate and all the ssl machinery. /david Daniel Frisk wrote: I'm trying to add a check to the constructor on one of our pages (a credit card processing page) which should: 1. If protocol is HTTPS; continue as usual 2. Else redirect so that HTTPS is used to access the same page I saw the sample in the wiki with the annotations that intercepted the request processing and etc but it seemed overly complicated for this tiny check, any ideas for a minimal implementation which could serve this purpose? // Daniel Frisk jalbum.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to HTTPS?
I have been attempting to get HTTPS/SSL working in my app too. Unfortunately, I have hit a wall...mostly b/c I am learning the API/Framework. In any case, the Example in the WIKI is outdated (v 1.2???) It won't work with 1.3 as is (no IResponseStrategy any more). However, I do believe I have figured out how to get SSL working with a little tweaking of this example. I haven't tested but I think the solution is to override public final CharSequence encode(final RequestCycle requestCycle,final IRequestTarget requestTarget)BUT...it is final so we can't reuse the class directly but have to make a copy. All the other encode methods get the proper wicket URL but doesn't prepend the webapp URI which this final encode method does. Beyond filing a RFE to either make this method non-final or provide a postEncode(RequestCycle, IRequestTarget) method before URL encoding, we will have to copy the entire class and provide this behavior. Thoughts? -- View this message in context: http://www.nabble.com/Redirect-to-HTTPS--tf4509537.html#a12872387 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]