You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Josip Gracin <gr...@tel.fer.hr> on 2006/06/18 18:13:30 UTC
Not solved! Re: Problem with mixing HTTP and HTTPS
Hello again!
After trying out the suggestion to use <security-constraint> in web.xml
(thanks Giampaolo!) I've figured out that it doesn't exactly solve my
problem. The problem is that I need to redirect to HTTPS for login and
some other subset of pages, and then after login, redirect back to HTTP.
By using <security-constrant> I am able to redirect to HTTPS, but there
doesn't seem to be a way to revert back to HTTP after the initial excursion.
I'm really getting pissed about this (and feeling more and more stupid
after each new failed attempt). Especially since the constraint to mix
HTTP and HTTPS pages has been forced upon me with the explanation that
everybody does it due to bad performance of HTTPS, which I'd give my
right arm if we would ever see in this particular application. :-(
Any other suggestions? Does anybody use a tapestry-based application in
which some pages are behind HTTPS while others are HTTP?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
R: R: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Giampaolo Tomassoni <g....@libero.it>.
> I have not used google analytics, so I don't know. In theory, it
> could/should still work. The original client ip is, afaik, included in
> the http header "X-Forwarded-For".
> It's pretty much as if the user uses a proxy server (i.e. a forward
> proxy, not a reverse proxy) - how does google analytics deal with
> that?
X-Forwarded-For is a hint for web servers. In apache, in example, page hits are always based on the connecting address, not on the X-Forwarded-For content. If the google staff did manage to handle it in code, well, fine. I don't think so, anyway. But have no proof either sides...
> Plus, I think they use cookies for the actual tracking, those should
> not be affected. But as I said, I have never used it, so I really
> can't be sure.
>
> I used mod_proxy it in the past to include some snippets provided on a
> site via plain html inside an https page. No kind of tracking was
> necessary.
Oh, well. Analytics is just a timed counter, after all. It should work anyway...
> hth, Lutz
>
> On 6/19/06, Giampaolo Tomassoni <g....@libero.it> wrote:
> > If this is done to fire a hit in google analytics, wouldn't
> google report the ip address and country of the server instead of
> the client's ones?
> >
> > giampaolo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Lutz Hühnken <lh...@googlemail.com>.
I have not used google analytics, so I don't know. In theory, it
could/should still work. The original client ip is, afaik, included in
the http header "X-Forwarded-For".
It's pretty much as if the user uses a proxy server (i.e. a forward
proxy, not a reverse proxy) - how does google analytics deal with
that?
Plus, I think they use cookies for the actual tracking, those should
not be affected. But as I said, I have never used it, so I really
can't be sure.
I used mod_proxy it in the past to include some snippets provided on a
site via plain html inside an https page. No kind of tracking was
necessary.
hth, Lutz
On 6/19/06, Giampaolo Tomassoni <g....@libero.it> wrote:
> If this is done to fire a hit in google analytics, wouldn't google report the ip address and country of the server instead of the client's ones?
>
> giampaolo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Kevin Menard <km...@servprise.com>.
On Mon, 19 Jun 2006 16:41:25 -0400, Lutz Hühnken""
<lh...@googlemail.com> wrote:
> Why would you not want to use an external mechanism? Is it not rather
> a feature of the framework to be "SSL agnostic"? I think more often
> than not people would keep, for example, security and access right
> aspects out of the application and deal with it declaratively. Now
> you're looking for a way to move http/https - switching into your
> application?
If it can be done in the page spec, and thus in an annotation, then you've
captured the logic in exactly one place. Should a page really care that
it should be rendered via HTTPS? Probably not. But, if I can annotate a
class with something like:
@Scheme("https")
and then inherit that via some hierarchy, I've just made my life a heck of
a lot easier.
Somewhere, it's going to need to be captured that the page must be
rendered via HTTPS. If it's done within the page, then at least I know if
I refactor, I haven't broken anything. Plus, I've saved myself the hassle
of doing things outside of the framework.
> Well, anyway: with Apache httpd, what you try to achieve is often done
> by using mod_rewrite. For https-only pages, the protocol part can be
> rewritten to https if the page is accessed via http, and vice versa.
> If the URL rewrite filter ("http://tuckey.org/urlrewrite/") does what
> it aspires (to be a very powerful tool just like Apache's
> mod_rewrite), it should allow you to do the same in a more portable
> way.
I actually use mod_rewrite to do this currently. It's great for switching
from HTTP to HTTPS. Going back is not so trivial. I've just abandoned
the idea for now.
> Talking about apache: including external content on https sites via
> http can in many cases be done without triggering warnings, by making
> a directory on your https server a reverse proxy using mod_proxy.
That's interesting. I'll have to take a look into it. It may be useful
for special corner cases, but not something I'd like to be doing in
general.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
R: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Giampaolo Tomassoni <g....@libero.it>.
> Talking about apache: including external content on https sites via
> http can in many cases be done without triggering warnings, by making
> a directory on your https server a reverse proxy using mod_proxy.
If this is done to fire a hit in google analytics, wouldn't google report the ip address and country of the server instead of the client's ones?
giampaolo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Lutz Hühnken <lh...@googlemail.com>.
What I don't understand: in an earlier posting you wrote:
On 5/29/06, Josip Gracin <gr...@tel.fer.hr> wrote:
[...]
> scheme, but relying only on Tapestry mechanisms, i.e. not using Tomcat etc.?
[...]
Why would you not want to use an external mechanism? Is it not rather
a feature of the framework to be "SSL agnostic"? I think more often
than not people would keep, for example, security and access right
aspects out of the application and deal with it declaratively. Now
you're looking for a way to move http/https - switching into your
application?
Well, anyway: with Apache httpd, what you try to achieve is often done
by using mod_rewrite. For https-only pages, the protocol part can be
rewritten to https if the page is accessed via http, and vice versa.
If the URL rewrite filter ("http://tuckey.org/urlrewrite/") does what
it aspires (to be a very powerful tool just like Apache's
mod_rewrite), it should allow you to do the same in a more portable
way.
Talking about apache: including external content on https sites via
http can in many cases be done without triggering warnings, by making
a directory on your https server a reverse proxy using mod_proxy.
hth,
Lutz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Josip Gracin <gr...@tel.fer.hr>.
Giampaolo Tomassoni wrote:
> You may develop a filter to be put on top of the tapestry servlet,
I'll check it out. Thanks for your time, I appreciate it!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Josip Gracin <gr...@tel.fer.hr>.
Kevin Menard wrote:
> What we (or at least I) want is to deal with this at the page class
> level. The idea would be a page class can either be marked as secure or
> not and the framework would then take care of rewriting URLs with the
> appropriate scheme. Such a system would allow for a nice hierarchy of
> secure pages and likewise would cut down on the human error element by
> letting the framework do most of the grunt work.
This sounds like exactly what I need. I've raised the issue in Jira
(http://issues.apache.org/jira/browse/TAPESTRY-991).
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Kevin Menard <km...@servprise.com>.
On Mon, 19 Jun 2006 10:30:38 -0400, Jesse Kuhnert <jk...@gmail.com>
wrote:
> Hard for me to have an opinion, but if there is a jira issue open for it
> I
> will try to remember to fix what inflexibility is being created with the
> current system.
I'm stretching my brain a bit here, but I think when this last came up,
the solution was the addition of the "scheme" attribute on links.
What we (or at least I) want is to deal with this at the page class
level. The idea would be a page class can either be marked as secure or
not and the framework would then take care of rewriting URLs with the
appropriate scheme. Such a system would allow for a nice hierarchy of
secure pages and likewise would cut down on the human error element by
letting the framework do most of the grunt work.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Jesse Kuhnert <jk...@gmail.com>.
Hard for me to have an opinion, but if there is a jira issue open for it I
will try to remember to fix what inflexibility is being created with the
current system.
On 6/19/06, Kevin Menard <km...@servprise.com> wrote:
>
> On Sun, 18 Jun 2006 12:41:43 -0400, Giampaolo Tomassoni
> <g....@libero.it> wrote:
>
> >> I'm really getting pissed about this (and feeling more and more stupid
> >> after each new failed attempt). Especially since the constraint to mix
> >> HTTP and HTTPS pages has been forced upon me with the explanation that
> >> everybody does it due to bad performance of HTTPS, which I'd give my
> >> right arm if we would ever see in this particular application. :-(
> >
> > Switching back to http was an old habit: five years ago, when internet
> > bandwidth were really narrow and cpu power wasn't that high, it could
> > have made a difference. Today these are not anymore issues. I would try
> > to stress this fact and the security issues the http/https mixup may
> > arise.
>
> There are actual reasons for switching back. E.g., we use Google
> Analytics, which requires linking to an external JavaScript file. The
> file is only hosted on HTTP. If I link to it from an HTTPS page, IE pops
> up and says "this page mixes secure and insecure resources -- do you want
> to continue?" The solution is to remove the link from any page accessed
> via HTTPS. If I can't switch back to HTTP, however, then it's a moot
> point because things will still break when users look at anything else on
> the site.
>
> It seems to me that if you're going to advocate not switching from HTTPS
> back to HTTP, then you're advocating not to bother with HTTP in the first
> place . . .
>
> --
> Kevin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: R: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Kevin Menard <km...@servprise.com>.
On Mon, 19 Jun 2006 10:43:07 -0400, Giampaolo Tomassoni
<g....@libero.it> wrote:
> Nah! Search engine don't access https and lazily browsing a site
> wouldn't require an https link as well. Nobody would advocate http
> support. But, again, when you enter an https there is a reason (a login
> or a credit card input form, in example). Once you input this kind of
> data, your session then contains private and important data. It must be
> protected by then.
You could just as easily clean up after you're all done. Presumably
there's a defined point at which you'd switch from HTTPS to HTTP. If you
know when you want to switch schemes, then you know when you want to purge
sensitive data from the session. Having the session ID at that point
won't really net you anything.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
R: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Giampaolo Tomassoni <g....@libero.it>.
> > Switching back to http was an old habit: five years ago, when internet
> > bandwidth were really narrow and cpu power wasn't that high, it could
> > have made a difference. Today these are not anymore issues. I
> would try
> > to stress this fact and the security issues the http/https mixup may
> > arise.
>
> There are actual reasons for switching back. E.g., we use Google
> Analytics, which requires linking to an external JavaScript file. The
> file is only hosted on HTTP. If I link to it from an HTTPS page,
> IE pops
> up and says "this page mixes secure and insecure resources -- do
> you want
> to continue?" The solution is to remove the link from any page accessed
> via HTTPS. If I can't switch back to HTTP, however, then it's a moot
> point because things will still break when users look at anything
> else on
> the site.
I would condition the google .js link to the http connection type... A user accessing my site from google would start surfing in http mode, not https, so the google's .js can still work. If he/she enters in a safe area, well, google analytics is a fine feature but is far less important than security and privacy to me.
> It seems to me that if you're going to advocate not switching from HTTPS
> back to HTTP, then you're advocating not to bother with HTTP in
> the first
> place . . .
Nah! Search engine don't access https and lazily browsing a site wouldn't require an https link as well. Nobody would advocate http support. But, again, when you enter an https there is a reason (a login or a credit card input form, in example). Once you input this kind of data, your session then contains private and important data. It must be protected by then.
> --
> Kevin
giampaolo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Kevin Menard <km...@servprise.com>.
On Sun, 18 Jun 2006 12:41:43 -0400, Giampaolo Tomassoni
<g....@libero.it> wrote:
>> I'm really getting pissed about this (and feeling more and more stupid
>> after each new failed attempt). Especially since the constraint to mix
>> HTTP and HTTPS pages has been forced upon me with the explanation that
>> everybody does it due to bad performance of HTTPS, which I'd give my
>> right arm if we would ever see in this particular application. :-(
>
> Switching back to http was an old habit: five years ago, when internet
> bandwidth were really narrow and cpu power wasn't that high, it could
> have made a difference. Today these are not anymore issues. I would try
> to stress this fact and the security issues the http/https mixup may
> arise.
There are actual reasons for switching back. E.g., we use Google
Analytics, which requires linking to an external JavaScript file. The
file is only hosted on HTTP. If I link to it from an HTTPS page, IE pops
up and says "this page mixes secure and insecure resources -- do you want
to continue?" The solution is to remove the link from any page accessed
via HTTPS. If I can't switch back to HTTP, however, then it's a moot
point because things will still break when users look at anything else on
the site.
It seems to me that if you're going to advocate not switching from HTTPS
back to HTTP, then you're advocating not to bother with HTTP in the first
place . . .
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
R: Not solved! Re: Problem with mixing HTTP and HTTPS
Posted by Giampaolo Tomassoni <g....@libero.it>.
> Hello again!
>
> After trying out the suggestion to use <security-constraint> in web.xml
> (thanks Giampaolo!) I've figured out that it doesn't exactly solve my
> problem. The problem is that I need to redirect to HTTPS for login and
> some other subset of pages, and then after login, redirect back to HTTP.
> By using <security-constrant> I am able to redirect to HTTPS, but there
> doesn't seem to be a way to revert back to HTTP after the initial
> excursion.
No, infact. The Servlet specs don't dictate a way to revert back to http. Also, in most cases such a mechanism is useless and even an hazard. Let say you make an https login, get your session cookie and revert back to http. In a men-in-the-middle case, a third person may see your cookie and impersonate the already logged-in user.
> I'm really getting pissed about this (and feeling more and more stupid
> after each new failed attempt). Especially since the constraint to mix
> HTTP and HTTPS pages has been forced upon me with the explanation that
> everybody does it due to bad performance of HTTPS, which I'd give my
> right arm if we would ever see in this particular application. :-(
Switching back to http was an old habit: five years ago, when internet bandwidth were really narrow and cpu power wasn't that high, it could have made a difference. Today these are not anymore issues. I would try to stress this fact and the security issues the http/https mixup may arise.
> Any other suggestions? Does anybody use a tapestry-based application in
> which some pages are behind HTTPS while others are HTTP?
You may develop a filter to be put on top of the tapestry servlet, issuing a redirect response to an http connection when https is not anymore needed. You just have to check for the transport guarantee level of the request and for the target of the request itself. If the guarantee level is not required, issue a redirect to the client instead of forwarding the request to the tapestry servelet. I wouldn't do the trick in higher layers, like the in tapestry app...
Regards,
-----------------------------------
Giampaolo Tomassoni - IT Consultant
Piazza VIII Aprile 1948, 4
I-53044 Chiusi (SI) - Italy
Ph: +39-0578-21100
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org