You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Gerald Schöffel <ta...@online.de> on 2006/01/26 14:49:12 UTC

https again and still absolutely clueless :(

Hi !

My first project at work I tried to use Tapestry for was canceled because of deadline constraints and some https-issues I could not solve at that time.

Ok, so I went back to Tapestry in my spare time - I think this framework is absolutely great. I want to use it for projects at work.

And now (getting around the Login-Page :) ) time is come to implement secure connections again :(

And I still have absolutely no idea, how to do this.

The 'scheme' binding used on links doesn't work for me - so there is no build in support for https in my point of view. Kent Tong gave me some hints at that time (building an own LinkRenderer) but I gave up because it got to complicated.

Why does the included scheme binding not work for me ? 

Examples:

Tomcat on local machine, port 8080. The link rendered when using https-scheme looks like:

https://localhost:8080/myApp/my.page :(

Using Apache as a proxy running on port 80, forwarding to localhost on port 8080, the link looks like:

https://mydomain:80/myApp/my.page :(

When using an own LinkRenderer I could solve this problem - but then I have to use this Renderer on all links on my site - not to comfortable.

So for me, Tapestry doesn't do the job (maybe there is a solution I am not aware of - so please tell it to me :) ).

Currently my planning is to move all secured pages in /WEB-INF/secure and use Apache as an proxy to forward this path to https (anyone aware of a source for downloading Apache binary with included ssl-support for Windows ? :) ).

But I am almost sure, that there is a solution out there.

So it would be great, if anyone could give me some hints (links or keywords) how to implement https 'the clever way' :)

Many thanks !!
Gerald

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Gerald Schöffel <ta...@online.de>.
Hi Johan,

>> https://localhost:8080/myApp/my.page :(
> 
> I am just curious but what is wrong with this generated link? It is an 
> absolute URL and it uses the https scheme. The port is probably not the 
> HTTPS listener port but how should Tapestry know which port to use? Is 
> this something you can configure?

In theory, this link is OK. But the port is exactly the problem in this 
case. As far as I figured out there is no option to tell Tapestry which 
port to use (without providing a LinkRenderer). It would be OK if there 
is no port - but in practice this model simply doesn't work (for me).

>>
>> Using Apache as a proxy running on port 80, forwarding to localhost on 
>> port 8080, the link looks like:
>>
>> https://mydomain:80/myApp/my.page :(
> 
> I know nothing about proxying with apache but is this not right? It 
> rewrites port 8080 to 80 which I would have guessed is what it should do.

The same is true for this one. Just remove the port and it would work ...

I don't know, where exactly the port number is coming from - maybe I 
should try Tomcat listening on port 80 directly to omit it ?

Gerald

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Johan Maasing <jo...@zoom.nu>.
Gerald Schöffel wrote:
> Hi !
> 
> My first project at work I tried to use Tapestry for was canceled because of deadline constraints and some https-issues I could not solve at that time.
> 
> Ok, so I went back to Tapestry in my spare time - I think this framework is absolutely great. I want to use it for projects at work.
> 
> And now (getting around the Login-Page :) ) time is come to implement secure connections again :(
> 
> And I still have absolutely no idea, how to do this.
> 
> The 'scheme' binding used on links doesn't work for me - so there is no build in support for https in my point of view. Kent Tong gave me some hints at that time (building an own LinkRenderer) but I gave up because it got to complicated.
> 
> Why does the included scheme binding not work for me ? 
> 
> Examples:
> 
> Tomcat on local machine, port 8080. The link rendered when using https-scheme looks like:
> 
> https://localhost:8080/myApp/my.page :(

I am just curious but what is wrong with this generated link? It is an 
absolute URL and it uses the https scheme. The port is probably not the 
HTTPS listener port but how should Tapestry know which port to use? Is 
this something you can configure?

> 
> Using Apache as a proxy running on port 80, forwarding to localhost on port 8080, the link looks like:
> 
> https://mydomain:80/myApp/my.page :(

I know nothing about proxying with apache but is this not right? It 
rewrites port 8080 to 80 which I would have guessed is what it should do.


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Gerald Schöffel <ta...@online.de>.
Fernando Padilla wrote:

 > Though not very clean I use a javax.servlet.Filter that locks down parts
 > of the site by redirecting to/fro http/https.
 >
 > Not the best/elegant option: 1) all dependent resources/images are https
 > when they don't have to be, 2) there are a few redirects that we
 > probably could do without.  But it does work for us quite nicely.
 >

Hi Fernando,

thank you for this reply !

This seems to be very logical. I was just reading the documentation of 
Acegi - and there is also the possibility to use a Filter to provide 
security.

So I do not think, that your solution is inelegant !

It is fine for directory based security constraints.

I actually do not know, what information is passed to such a Filter, but 
I guess it is 'just' http-stuff - far away from the Tapestry side of 
life ? :)

Would be great to get such a filter more 'into' Tapestry to implement 
constraints based on page/component properties or meta-data ... hmmm ... 
sounds really cool !

So I have to figure out where in the cycle such a service has to be 
injected ... if this is even possible.

That was a cool keyword :)

Thank you very much !!

Gerald

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Fernando Padilla <fe...@alum.mit.edu>.
Though not very clean I use a javax.servlet.Filter that locks down parts 
of the site by redirecting to/fro http/https.

So if a url coming in points to any of those pages I make sure that it's 
request.isSecure, else I get the full url and replace the scheme( 
http,https ) and port( 80,443 ), and sendRedirect.  After it's been 
moved onto the https area, tapestry generates all of the urls consistent 
with that, keeping all references within the https area.  And once they 
try to go to a unsecure part of the site, we redirect them onto the http 
url.

Not the best/elegant option: 1) all dependent resources/images are https 
when they don't have to be, 2) there are a few redirects that we 
probably could do without.  But it does work for us quite nicely.

http://www.protrade.com/



Gerald Schöffel wrote:
> Hi !
> 
> My first project at work I tried to use Tapestry for was canceled because of deadline constraints and some https-issues I could not solve at that time.
> 
> Ok, so I went back to Tapestry in my spare time - I think this framework is absolutely great. I want to use it for projects at work.
> 
> And now (getting around the Login-Page :) ) time is come to implement secure connections again :(
> 
> And I still have absolutely no idea, how to do this.
> 
> The 'scheme' binding used on links doesn't work for me - so there is no build in support for https in my point of view. Kent Tong gave me some hints at that time (building an own LinkRenderer) but I gave up because it got to complicated.
> 
> Why does the included scheme binding not work for me ? 
> 
> Examples:
> 
> Tomcat on local machine, port 8080. The link rendered when using https-scheme looks like:
> 
> https://localhost:8080/myApp/my.page :(
> 
> Using Apache as a proxy running on port 80, forwarding to localhost on port 8080, the link looks like:
> 
> https://mydomain:80/myApp/my.page :(
> 
> When using an own LinkRenderer I could solve this problem - but then I have to use this Renderer on all links on my site - not to comfortable.
> 
> So for me, Tapestry doesn't do the job (maybe there is a solution I am not aware of - so please tell it to me :) ).
> 
> Currently my planning is to move all secured pages in /WEB-INF/secure and use Apache as an proxy to forward this path to https (anyone aware of a source for downloading Apache binary with included ssl-support for Windows ? :) ).
> 
> But I am almost sure, that there is a solution out there.
> 
> So it would be great, if anyone could give me some hints (links or keywords) how to implement https 'the clever way' :)
> 
> Many thanks !!
> Gerald
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Alan Chandler <al...@chandlerfamily.org.uk>.
On Friday 27 January 2006 16:17, Cliff Zhao wrote:
> I'm not a Apache expert, but I think that you can have Apache redirect your
> pages. Namely, when Apache gets http requests supposed to be https, Apache
> will redirect them to the https equivalent.
>

I think you have to be quite careful.  The https causes the browser to 
negotiate the encryption, so you can't use apache to randomly change incoming 
protocols.

I am not I understand the problem from earlier discussion in this thread. 
However ...

I run an application that I want to be https when accessed from the internet 
(so that the basic authentication is properly encrypted - as well as the fact 
that the application is displaying sensitive financial data), but uses http 
when accessed from in tmy local area network.  I have tomcat front ended by 
apache (which I use for all my security control). Effectively inside apache I 
have almose identical virtual host configurations for the two (by using a 
common include file and then use rewrite rules to block access from the 
internet to non https protocols.  This acutally causes the user to see an 
error message if he tries it. However, tapestry builds urls in the correct 
protocol (http or https) as the incoming request.

In order to get it to allow logon to selected areas, I use basic 
authentication (actually its enhanced to look up users and groups in a 
database) controlled via <location> blocks within the apache configuration.  
I gave up on tomcat's validation when I realised it didn't work with apache 
in from of it.

What I suspect is being asked here is that when moving from one part of the 
application to another that you transition from http to https.  In Tapestry 4 
I beleive that what the "scheme" parameter is on the @DirectLink and 
@PageLink components is about.

Even so, in this case, I think you will need separate virtual hosts inside 
apache for the http and https parts as http will be received on port 80 and 
https on port 443. 

-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Cliff Zhao <zh...@gmail.com>.
I'm not a Apache expert, but I think that you can have Apache redirect your
pages. Namely, when Apache gets http requests supposed to be https, Apache
will redirect them to the https equivalent.

Personally, I really like this kind of things be configured on Apache.

On 1/27/06, Gerald Schöffel <ta...@online.de> wrote:
>
> Hi Chris, me again :)
>
> >
> > Yes, those port numbers will go away completely.  This is because Apache
> > won't even be talking to Tomcat on port 8080, it will be using the JK
> > port, 8009.  Using mod_jk makes Tomcat work much more like mod_php or
> > mod_perl.  All of the http/https stuff happens in Apache.  So when a
> > request comes in Apache uses mod_jk to request the (X)HTML (or whatever)
> > document from Tomcat instead of retrieving a file from the disk.  Then
> > Apache responds with whatever Tomcat sent.  From Tomcat's point of view,
> > there is no http or https.
>
> That sounds really great. But I think I am getting to old for those
> things ...
>
> I just downloaded the connector and installed it on my server.
>
> Because things are very new to me, I used a minimal configuration
> (without virtual hosts). So I put the following into my httpd.conf:
>
> LoadModule jk_module modules/mod_jk.so
>
> JkWorkerProperty worker.list=ajp13w
> JkWorkerProperty worker.ajp13w.type=ajp13
> JkWorkerProperty worker.ajp13w.host=localhost
> JkWorkerProperty worker.ajp13w.port=8009
> JkLogFile c:/jk_log.log
> JkLogLevel info
>
> JkMount /myApp/* ajp13w
>
> In server.xml there is the following
>
>      <Connector
>          port="8009"
>          redirectPort="8443"
>          protocol="AJP/1.3">
>      </Connector>
>
>
> So a very basic setup.
>
> And the connection is running very well - even when I install some
> html-files in htdocs in the same directory I have mapped Tomcat to,
> Apache will serve the Tomcat stuff. Cool :)
>
> But:
>
> Despite the fact that I am calling my app without the port number (using
> http://localhost/myApp) the link rendered by Tapestry when using scheme
> https still looks like:
>
> https://localhost:80/myApp/myPage.page :(
>
> Every html-link is rendered ok (http://localhost/myApp/myPage.page)
> without the port number.
>
> I have tried every connection (from outside with my domain-name, via
> 127.0.0.1, from another computer using the servers ip, and the windows
> name of the server) - I even configured Apache to listen to port 500 :)
> (the https link then was https://localhost:500/Myapp/myPage.page).
>
> I even upgraded to Tapestry 4.0 final (was using Rc1 till now).
>
> So I am clueless again :(
>
> In my configuration (maybe there is some configuration point in Tomcat
> or Apache I am not aware of that forces this behaviour ?) this scheme
> thing seems to be absolutely useless :(
>
> So I will focus on this filter-thing Fernando mentioned to implement
> path or page/component based https-connections.
>
> But I still wonder if I am the only person around trying to use the
> scheme https ?
>
> Bye,
> Gerald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Re: https again and still absolutely clueless :(

Posted by Gerald Schöffel <ta...@online.de>.
Hi Chris, me again :)

> 
> Yes, those port numbers will go away completely.  This is because Apache 
> won't even be talking to Tomcat on port 8080, it will be using the JK 
> port, 8009.  Using mod_jk makes Tomcat work much more like mod_php or 
> mod_perl.  All of the http/https stuff happens in Apache.  So when a 
> request comes in Apache uses mod_jk to request the (X)HTML (or whatever) 
> document from Tomcat instead of retrieving a file from the disk.  Then 
> Apache responds with whatever Tomcat sent.  From Tomcat's point of view, 
> there is no http or https.

That sounds really great. But I think I am getting to old for those 
things ...

I just downloaded the connector and installed it on my server.

Because things are very new to me, I used a minimal configuration 
(without virtual hosts). So I put the following into my httpd.conf:

LoadModule jk_module modules/mod_jk.so

JkWorkerProperty worker.list=ajp13w
JkWorkerProperty worker.ajp13w.type=ajp13
JkWorkerProperty worker.ajp13w.host=localhost
JkWorkerProperty worker.ajp13w.port=8009
JkLogFile c:/jk_log.log
JkLogLevel info

JkMount /myApp/* ajp13w

In server.xml there is the following

     <Connector
         port="8009"
         redirectPort="8443"
         protocol="AJP/1.3">
     </Connector>


So a very basic setup.

And the connection is running very well - even when I install some 
html-files in htdocs in the same directory I have mapped Tomcat to, 
Apache will serve the Tomcat stuff. Cool :)

But:

Despite the fact that I am calling my app without the port number (using 
http://localhost/myApp) the link rendered by Tapestry when using scheme 
https still looks like:

https://localhost:80/myApp/myPage.page :(

Every html-link is rendered ok (http://localhost/myApp/myPage.page) 
without the port number.

I have tried every connection (from outside with my domain-name, via 
127.0.0.1, from another computer using the servers ip, and the windows 
name of the server) - I even configured Apache to listen to port 500 :) 
(the https link then was https://localhost:500/Myapp/myPage.page).

I even upgraded to Tapestry 4.0 final (was using Rc1 till now).

So I am clueless again :(

In my configuration (maybe there is some configuration point in Tomcat 
or Apache I am not aware of that forces this behaviour ?) this scheme 
thing seems to be absolutely useless :(

So I will focus on this filter-thing Fernando mentioned to implement 
path or page/component based https-connections.

But I still wonder if I am the only person around trying to use the 
scheme https ?

Bye,
Gerald

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


RE: https again and still absolutely clueless :(

Posted by Patrick Casey <pa...@adelphia.net>.
> A nice side benefit is you get to use Apache's native SSL
> implementation which is orders of magnitude faster then the terribly
> slow Java SSL implementation.

	My understanding is that this hasn't been true since the 1.4 JVM
e.g. java's ssl package has gotten a *lot* faster and now comes very close
to compiled ssl implementations in performance. I can't seem to find any
number one way or the other though, so am I hallucinating here, or is this
another one of those cases where Sun eventually fixed their performance
problems?

	--- Pat




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Chris Conrad <cc...@vasoftware.com>.
Hi Gerald,

On Jan 26, 2006, at 1:22 PM, Gerald Schöffel wrote:

> Hello Chris,
>
>> If you're using Tomcat (or another servlet container that supports  
>> the JK protocol) this is quite easy to handle.  First you need to  
>> set up two virtual hosts in your Apache config, a regular host  
>> listening on port 80 and an SSL host listening on port 443.  Each  
>> of those virtual hosts is set to use mod_jk to forward to your  
>> Tomcat instance.  By using mod_jk, all of the port stuff goes away  
>> from your URLs.  Apache handles all the SSL stuff so Tomcat  
>> doesn't need to do it.  And you should require no code changes,  
>> the scheme binding will just work.
>> Hope that helps
>
> Yes, I think this is very helpful !
>
> Thank you for pointing this out. At this time, my Apache is only  
> using mod_proxy - I did not know how powerful mod_jk is in  
> combination with Tapestry :)

If you're fronting Tomcat with Apache mod_jk is very powerful.

> So when using mod_jk the parasitic port ending mentioned in my  
> initial posting will be gone ? Cool !

Yes, those port numbers will go away completely.  This is because  
Apache won't even be talking to Tomcat on port 8080, it will be using  
the JK port, 8009.  Using mod_jk makes Tomcat work much more like  
mod_php or mod_perl.  All of the http/https stuff happens in Apache.   
So when a request comes in Apache uses mod_jk to request the (X)HTML  
(or whatever) document from Tomcat instead of retrieving a file from  
the disk.  Then Apache responds with whatever Tomcat sent.  From  
Tomcat's point of view, there is no http or https.

A nice side benefit is you get to use Apache's native SSL  
implementation which is orders of magnitude faster then the terribly  
slow Java SSL implementation.

Just remember, when you configure things this way, Tomcat really  
isn't doing the https processing so you need to install your SSL  
certificates on the Apache server, not on Tomcat.

--Chris


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Gerald Schöffel <ta...@online.de>.
Hello Chris,

> If you're using Tomcat (or another servlet container that supports the 
> JK protocol) this is quite easy to handle.  First you need to set up two 
> virtual hosts in your Apache config, a regular host listening on port 80 
> and an SSL host listening on port 443.  Each of those virtual hosts is 
> set to use mod_jk to forward to your Tomcat instance.  By using mod_jk, 
> all of the port stuff goes away from your URLs.  Apache handles all the 
> SSL stuff so Tomcat doesn't need to do it.  And you should require no 
> code changes, the scheme binding will just work.
> 
> Hope that helps

Yes, I think this is very helpful !

Thank you for pointing this out. At this time, my Apache is only using 
mod_proxy - I did not know how powerful mod_jk is in combination with 
Tapestry :)

So when using mod_jk the parasitic port ending mentioned in my initial 
posting will be gone ? Cool !

Together with Fernandos idea I now have plenty of options and keywords 
to play with.

I think I will start using this mod_jk-configuration to get things done 
and to accelerate the progress of my application - moving toward the 
filter solution for fine grained constraints.

So kudos to you and Fernando !

Thanks again,
Gerald <- very happy now :)








---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: https again and still absolutely clueless :(

Posted by Chris Conrad <cc...@vasoftware.com>.
Hi Gerald,

If you're using Tomcat (or another servlet container that supports  
the JK protocol) this is quite easy to handle.  First you need to set  
up two virtual hosts in your Apache config, a regular host listening  
on port 80 and an SSL host listening on port 443.  Each of those  
virtual hosts is set to use mod_jk to forward to your Tomcat  
instance.  By using mod_jk, all of the port stuff goes away from your  
URLs.  Apache handles all the SSL stuff so Tomcat doesn't need to do  
it.  And you should require no code changes, the scheme binding will  
just work.

Hope that helps
--Chris

On Jan 26, 2006, at 5:49 AM, Gerald Schöffel wrote:

> Hi !
>
> My first project at work I tried to use Tapestry for was canceled  
> because of deadline constraints and some https-issues I could not  
> solve at that time.
>
> Ok, so I went back to Tapestry in my spare time - I think this  
> framework is absolutely great. I want to use it for projects at work.
>
> And now (getting around the Login-Page :) ) time is come to  
> implement secure connections again :(
>
> And I still have absolutely no idea, how to do this.
>
> The 'scheme' binding used on links doesn't work for me - so there  
> is no build in support for https in my point of view. Kent Tong  
> gave me some hints at that time (building an own LinkRenderer) but  
> I gave up because it got to complicated.
>
> Why does the included scheme binding not work for me ?
>
> Examples:
>
> Tomcat on local machine, port 8080. The link rendered when using  
> https-scheme looks like:
>
> https://localhost:8080/myApp/my.page :(
>
> Using Apache as a proxy running on port 80, forwarding to localhost  
> on port 8080, the link looks like:
>
> https://mydomain:80/myApp/my.page :(
>
> When using an own LinkRenderer I could solve this problem - but  
> then I have to use this Renderer on all links on my site - not to  
> comfortable.
>
> So for me, Tapestry doesn't do the job (maybe there is a solution I  
> am not aware of - so please tell it to me :) ).
>
> Currently my planning is to move all secured pages in /WEB-INF/ 
> secure and use Apache as an proxy to forward this path to https  
> (anyone aware of a source for downloading Apache binary with  
> included ssl-support for Windows ? :) ).
>
> But I am almost sure, that there is a solution out there.
>
> So it would be great, if anyone could give me some hints (links or  
> keywords) how to implement https 'the clever way' :)
>
> Many thanks !!
> Gerald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org