One of the problems is the seeOther() takes a uri not a URL so the context for the redirect is the same. So the port remains the same.
On Mon, Mar 5, 2012 at 7:49 AM, Paul Read <[email protected]> wrote: > Hi Sergey > > Try as I may I have been unable to get this to work. The main problem > seems to be defining http and https endpoints in the same tomcat and > web.xml using cxf and rest. If I use the address property on the rest > endpoint it tries to pull in Jetty. Can this be done? > > Thanks > > Paul > > On Mon, Feb 20, 2012 at 6:16 PM, Sergey Beryozkin <[email protected]> > wrote: >> Hi, >> >> On 20/02/12 23:10, Paul Read wrote: >>> >>> Sergey >>> >>> Yes that looks extactly what I need ! This is the coolest solution! >>> >>> If I may ask...for endpoint 1 path 2, would the HttpRequest now have >>> the cert information or would I have to save it in the session object >>> at endpoint 2, or in a spring request object? >>> >> >> I suspect you would need to use some custom mechanism for making the certs >> captured in the https path available to the endpoint 1/path2. >> >> I'm not sure if it's possible to share the same session between https & http >> invocation - probably not, but I haven't tried :-). >> >> Cheers, Sergey >> >> >> >>> Thanks >>> >>> Paul >>> >>> On Mon, Feb 20, 2012 at 5:35 PM, Sergey Beryozkin<[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> On 20/02/12 20:28, pdread wrote: >>>>> >>>>> >>>>> >>>>> Ok. I have done cxf considerable so I know I can grab the cert from the >>>>> request, and I usually use an interceptor but on this new project with >>>>> this >>>>> new company they don't use any framework other than servlets. Not even >>>>> spring. >>>>> >>>>> Now what I mean by grabbing the client certificate is still using TLS ( >>>>> I >>>>> think) but not in the "normal" vain that most would expect. The current >>>>> app >>>>> does a redirect, from http port 8080 to https port 8443. This redirect >>>>> causes the browser to present >>>>> the client certificate in the normal manner and it is captured for later >>>>> processing, after the certificate is captured the comms is redirected >>>>> back >>>>> to http port 8080 and the processing continues. >>>>> >>>>> I guess I don't really mean not use https but more like, how can I, in >>>>> one >>>>> request, go from http to https, get the cert, then go back to http and >>>>> the >>>>> REST service. >>>>> >>>>> I've seen cxf can do redirects and was wonder if this could be done but >>>>> I'm >>>>> not versed enough to figure it out. It would be a big feather in my cap >>>>> if >>>>> I >>>>> could do this since the altimate customer wants this done like yesterday >>>>> and >>>>> I'm holding things up trying to bring new tech into their hack and slash >>>>> world. >>>>> >>>> >>>> I'm wondering if you are after something like this: >>>> >>>> 1. have one endpoint listening on the unsecured http port, have the >>>> service >>>> class like this: >>>> @Path("http") >>>> public class HttpService { >>>> private @Context UriInfo ui; >>>> >>>> private String httpsUri; >>>> >>>> @Path("1") >>>> @GET >>>> public Response one() { >>>> return Response.seeOther(httpsUri).build() >>>> } >>>> >>>> @Path("2") >>>> @GET >>>> public Response two() { >>>> } >>>> >>>> } >>>> >>>> >>>> Endpoint 2: >>>> >>>> @Path("https") >>>> public class HttpService { >>>> private @Context UriInfo ui; >>>> >>>> private String httpUri2; >>>> >>>> @GET >>>> public Response theHttps() { >>>> // grab the certs at the interceptor level, and now redirect back to >>>> @Path("2") in the prev endpoint >>>> return Response.seeOther(httpUri2).build() >>>> } >>>> >>>> } >>>> >>>> Something like that ? >>>> >>>> Cheers, Sergey >>>> >>>> >>>>> Thanks >>>>> >>>>> Paul >>>>> >>>>> -- >>>>> View this message in context: >>>>> >>>>> http://cxf.547215.n5.nabble.com/http-https-http-and-REST-tp5497801p5500178.html >>>>> Sent from the cxf-user mailing list archive at Nabble.com. >>>> >>>> >>>> >>>> >>>> -- >>>> Sergey Beryozkin >>>> >>>> Talend Community Coders >>>> http://coders.talend.com/ >>>> >>>> Blog: http://sberyozkin.blogspot.com >> >>
