Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #10273 (closed)

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

Bug: webstart urls hardcoded

Reported by: wmoore Owned by: atarkowska
Priority: critical Milestone: OMERO-4.4.9
Component: Web Version: 4.4.8
Keywords: n.a. Cc: cxallan, jburel, jamoore, atarkowska, m.woodbridge@…, julien.jourde@…
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: Blocker 4.4.9 (1)

Description

From ome-users:

On 01.02.2013 15:09, Julien Jourde wrote:
Hi Omero-users,

I just installed a 4.4.5 omero server in my lab. Everything's fine
except when I try to launch Insight using the jnlp protocol.

The problem seems to come from the redirection of the port 80 to the
port 443 in nginx.

I'm using "rewrite https://$server_name$request_uri? permanent;" in my
omero.conf file to accomplish that. But the jnlp file can't deal with
that. It contains urls like
"http://my.omero.server.fr/webstart/jars/insight.jnlp" where it shoud be
"https://my....". Launching the jnlp leads to a launchfile error because
it tries to charge a web page unproperly created by nginx (see below).

Did I made something wrong by using redirection rules ? Is there a way
to do it more properly ?

On 01.02.2013 15:12, Niko Ehrenfeuchter wrote:

apparently we do have an exception for webstart in the rewrite rules:

if ( $uri !~ /webstart/jars/insight.jnlp ) {

rewrite https://$server_name$request_uri? last;

}

This workaround seems to get things going here, but anyway I think the hardcoded "http" in the jnlp file should rather get fixed.

Cheers
Niko

Attachments (1)

OMERO.insightScreenSnapz001.jpg (31.3 KB) - added by atarkowska 11 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 11 years ago by jmoore

  • Cc m.woodbridge@… julien.jourde@… added
<%@ page contentType="application/x-java-jnlp-file" %>
<?xml version="1.0" encoding="utf-8"?>
<jnlp
 codebase="<%= request.getRequestURL().substring(0, request.getRequestURL().lastIndexOf("/") + 1) %>"
 href="<%= request.getRequestURL().substring(request.getRequestURL().lastIndexOf("/") + 1) %>">
 ...
 <resources>
   <j2se version="1.5.0+" max-heap-size="256m"/>
   <jar href="omero.insight.jar"/>
   <jar href="config.jar"/>
   <jar href="libs/xalan-2.7.1.jar"/>
   ...
 </resources>
 <application-desc/>
</jnlp>

Seehttp://lists.openmicroscopy.org.uk/pipermail/ome-users/2013-February/003515.html

comment:2 Changed 11 years ago by jburel

  • Sprint changed from 2013-02-12 (5) to 2013-03-12 (6))

Moved from sprint 2013-02-12 (5)

comment:3 Changed 11 years ago by jburel

  • Sprint changed from 2013-03-12 (6)) to 2013-04-09 (7))

Moved from sprint 2013-03-12 (6))

comment:4 Changed 11 years ago by wmoore

Chris - having discussed this with Blazej and Kenny, we're no closer to understanding what the fundamental issue (and fix) is. Not sure if the problems above are caused by deployment settings or code bugs. The urls within the webstart/jars/insight.jnlp are generated with the same http / https prefix as the request.

Let me know if we need to fix the code, or improve docs or neither.
Cheers,

comment:5 Changed 11 years ago by jburel

  • Sprint changed from 2013-04-09 (7)) to 2013-05-07 (8)

Moved from sprint 2013-04-09 (7))

comment:6 Changed 11 years ago by wmoore

  • Owner changed from wmoore to cxallan

Chris, could you have a look at this (see comments above)? Cheers,

comment:7 Changed 11 years ago by jburel

  • Sprint changed from 2013-05-07 (8) to Blocker 4.4.9 (1)

Moved from sprint 2013-05-07 (8)

comment:8 Changed 11 years ago by atarkowska

  • Cc atarkowska added
  • Version set to 4.4.8

comment:9 Changed 11 years ago by jamoore

  • Owner changed from cxallan to atarkowska

Passing to Ola for evaluation.

comment:10 Changed 11 years ago by atarkowska

I've been playing with that issue, but I can't reproduce it.

We have SSL on on one of ours teaching environments and we do not experience that issue:

<?xml version="1.0" encoding="utf-8"?>
<jnlp codebase="https://learning.openmicroscopy.org/dundee/static/webstart/jars/" href="https://learning.openmicroscopy.org/dundee/webstart/jars/insight.jnlp">
  <information>
    <title>OMERO.insight</title>
    ...
    <j2se version="1.5+" max-heap-size="1024m"/>
    <jar href="omero.insight.jar"/>
    ...
    <jar href="jaxrpc.jar"/>
    <property name="jnlp.omero.host" value="localhost"/>
    <property name="jnlp.omero.port" value="4064"/>
  </resources>
  <application-desc main-class="org.openmicroscopy.shoola.Main"/>
</jnlp>

and nginx config


server {
    listen         80 default;
    server_name    ...
    rewrite        ^ https://$server_name$request_uri? permanent;
}

server {

    listen       443 default ssl;

    ssl on;
    ssl_certificate ...
    ...

    location /omero/ {
        ...
        fastcgi_param HTTPS on;

Last edited 11 years ago by atarkowska (previous) (diff)

Changed 11 years ago by atarkowska

comment:11 Changed 11 years ago by atarkowska

  • Resolution set to worksforme
  • Status changed from new to closed

Closing for now as it works for me

comment:12 Changed 11 years ago by atarkowska

It looks like fastcgi_param HTTPS was missed. See here

Last edited 11 years ago by atarkowska (previous) (diff)

comment:13 Changed 10 years ago by khgillen

We should include a commented out HTTPS section in the nginx config which includes this, upon bin/omero web nginx.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.67806 sec.)

We're Hiring!