[rfc][icedtea-web] Headless Security Dialogs

[Jiri Vanek]

On 05/22/2014 10:22 PM, Lukasz Dracz wrote:
> Hello,
>
> This patch is aimed at fixing the bug PR 1764 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1764
> I have added checks for the headless parameter and based on the user's security level setting for extended applets it
> decides whether to allow or disallow an app to run. I have attached a document in .odt file format with an overview
> and justifications or assumptions for the decisions I have made. If a different file format is required feel free to message
> me and I will do my best to get you the document in a format readable for you. Any suggestions or comments
> would be appreciated.
>
> 2014-05-21  Lukasz Dracz  <ldracz at redhat.com>
>
> 	* netx/net/sourceforge/jnlp/security/SecurityDialogs.java:
> 	added checks for headless, and a behaviour based on the security dialog
> 	and security level as to whether allow or disallow an app to run
>

Hi. This is not an review. Jut few evil hints ;)
- the odt doccumet - Although I understand why you used it,and it is *good* in this case. I would strongly discourage you aganst posting such binary attachements. Dont forget that distro archives are accesisble from web, and one can simplynot view such ana attachement.
Soem paste bin with rich formating, or simple plantext with tabs may serve in similar way.

Code
  -  There is huge amount of coypasted code. This must not be.
  - headless applets are practically nonsense (they run in webpage, in browser, in X mode... :) )
    but
  - most of the dialogs are valid also for javaws. So you should use application instead of appelt, or - better - decide if it is appelt or application what is running
   - but as those lienes are really for javaws, I would recomamnd usage of "application".
  - alignment of long lines. .. just think about it :)



General hint - does een have snese to use such an dialogues in headles mode? I mean, if the check will return mostly "false" then the app wil not run at all...

Also I think this is misusing a AppletSecurityLevel.ALLOW_UNSIGNED in HUGE vector. Andrew A once sugested new item here. Sometink like BLINDLY_TRUST_ALL. I'm hesitating with introduction of this, but it may be better then missus this ALLOW_UNSIGNED

J.


ps. I generally agree with this patch.