You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Daniel Frisk <da...@jalbum.net> on 2007/09/24 16:24:28 UTC
Redirect to HTTPS?
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <da...@jalbum.net> 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 <da...@jalbum.net> 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: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Redirect to HTTPS?
Posted by Daniel Frisk <da...@jalbum.net>.
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 <da...@jalbum.net> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <da...@jalbum.net> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Redirect to HTTPS?
Posted by David Bernard <dw...@free.fr>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/24/07, Daniel Frisk <da...@jalbum.net> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Doug Leeper <do...@yahoo.com>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Doug Leeper <do...@yahoo.com>.
I tested and it appears to work as expected. I have updated the Wiki to
explain the steps involved for getting this to work in your application.
Now I need to figure out how to get Jetty 4.2.24 to listen on an SSL port.
Any idea?
--
View this message in context: http://www.nabble.com/Redirect-to-HTTPS--tf4509537.html#a12872701
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Daniel Frisk <da...@jalbum.net>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Claudio Miranda <cl...@claudius.com.br>.
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-name>ssl-test</display-name>
<web-resource-collection>
<web-resource-name>resultado</web-resource-name>
<description/>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>HEAD</http-method>
<http-method>PUT</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<user-data-constraint>
<description>ssl mode</description>
<transport-guarantee>CONFIDENTIAL</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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Claudio Miranda <cl...@claudius.com.br>.
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-name>ssl-test</display-name>
<web-resource-collection>
<web-resource-name>resultado</web-resource-name>
<description/>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>HEAD</http-method>
<http-method>PUT</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<user-data-constraint>
<description>ssl mode</description>
<transport-guarantee>CONFIDENTIAL</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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by John Patterson <jd...@gmail.com>.
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?
Posted by Tim L Casey <tc...@cataphora.com>.
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:wicket@leangen.net]
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by David Leangen <wi...@leangen.net>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Doug Leeper <do...@yahoo.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by David Leangen <wi...@leangen.net>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Doug Leeper <do...@yahoo.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Redirect to HTTPS?
Posted by Doug Leeper <do...@yahoo.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org