Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36577

Re: Breaking JNLP apps

Show all headers | View raw

Andreas Leitgeb <avl@logic.at> wrote:
> Ok now, about 3 years later, I've finally been making some progress. I did
> get the app running on an 1.8.0_131 client, but face some restrictions,
> which (if I can't solve them) would complicate the deployment quite a bit.
>
> The problem is about the jnlp-templates: I can successfully replace *some*
> parts like the <jnlp codebase="..."> or <title>...</title> value with a *,
> but if I try to use wildcards for a custom property:
>     <property name="jnlp.myapp.foo" value="*"/>
> in the <resources> section, then the signature verification fails, no
> matter what was the actual value in the downloaded myapp.jnlp. (even,
> if it had a literal "*" there thus being equal to the template!)

I think, I found the relevant (though vague) "documentation" of my 
observations in the jnlp specification (Section 5.4.1):

" The template (APPLICATION_TEMPLATE.JNLP) may have fields for CDATA
" arguments or values denoted as "*".   [...]  An element value or
" attribute value matches if either the value in the template is
" identical to the value in the JNLP file used to launch the app,

Well, that isn't true, because it didn't even accept "*" in the 
downloaded jnlp where the template had "*" for some property's value.

" or all of the following are true:
" - [...] of type CDATA [...] or #PCDATA
" - [...] value in the signed template is "*"
" - [...] value is not blacklisted or restricted by the JNLP Client

" It is expected that a JNLP Client will blacklist [...] jnlp elements
" and argument values such as "java-vm-args" or property "name" and "value" 

Given that properties already have to start with "jnlp." (or "javaws.")
to be even definable in the jnlp file, and the template is signed in
the jar file (thus noone can cheat a "*" into the template that the
author didn't expect), then this restriction makes zero sense.


I've also found other resources on the net dealing with similar
problems, like e.g.:
http://stackoverflow.com/questions/19883525/wildcards-in-jnlp-template-file
which only complains about * not being able to match nested <argument>
tags, but doesn't seem to have problems with "*" values for properties.
That's 4 years ago; seems like 1.8.0's Jnlp-client has become even more
restrictive, since.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Breaking JNLP apps Andreas Leitgeb <avl@logic.at> - 2017-04-29 00:11 +0000
  Re: Breaking JNLP apps Andreas Leitgeb <avl@logic.at> - 2017-05-02 18:23 +0000

csiph-web