Flash going away

[Toby]

Going through some updates on my PC, including Google Chrome, which says....

Flash Player will no longer be supported after December 2020.

I think that means Union Admin will no longer work in browsers (is there any other way?).

This has been in the cards for a while, but now there is a deadline.

Where Google Chrome goes, the others follow -- so there may be working browsers around after that,

but who wants an extra browser in use just because of one app?

Makes the issue kind of urgent, doesn't it?

Anyone?

P.S. I have just gone through "death by software no longer available" with Flash's cousin Shockwave.

It was required for a game I play, but when I got this new computer and went to download it,

Adobe said, "Sorry, boss, no can do!" That is what will happen with Flash in due course.

See also this related thread:  Union Admin on JS

https://groups.google.com/forum/#!topic/unionplatform/ADvVUnHhN20

[Chris R]

Union Admin works for me as desktop app on macOS by double clicking like any other app. Standalone Flash Player comes with Adobe Animate. Just checked and there is a standalone .exe version in my player directory also (see screen grab). 

Possible workaround:

Install Trial version of Animate, which should install standalone players for both platforms. Or contact Adobe about an install link for standalone player.

[Toby]

Thanks for the heads up on stand alone flash player.

Following the instructions here:

https://www.howtogeek.com/438141/how-to-play-adobe-flash-swf-files-outside-your-web-browser/

I was able to download and use it.

However, in order for it to work, the  line in union.xml:

 <access_control_allow_origin>*</access_control_allow_origin>

has to be like that, or simply not be there.

Is there a way to allow my PC to get in (along with using the in-browser version on my domain)

without allowing the whole world a back door?

[Chris R]

I use a password for admin access.

    <server>

        <admin>

            <port>9110</port>

       <password>password</password>

        </admin>

    </server>

I tried limiting to my IP using the tag you mentioned and also by policy.xml but no go. Since password works I gave up, but would be much better if I could also limit to my IP.

Caution - per this link:

http://www.unionplatform.com/?page_id=416

When changing the server password, be sure to also change password in stopserver.sh, otherwise, the server will refuse attempts to stop the server, and will output the following error message: Login refused [AUTHORIZATION_FAILED].

I changed password  in union.xml but not stopserver.sh. Had to reboot server to fix.

[Toby]

I tried limiting to my IP using the tag you mentioned and also by policy.xml but no go. Since password works I gave up, but would be much better if I could also limit to my IP.

Oh! I thought that would work, after reading Adobe documentation which says:

allow-access-from may have the following attributes:

domain: Specifies a requesting domain to be granted access.
Both named domains and IP addresses are acceptable values.

 

Although using a hard-coded IP address is rather crude!

I guess password provides some security.

Also, you said:

I changed password  in union.xml but not stopserver.sh. Had to reboot server to fix.

It shouldn't be necessary to reboot the whole server - just the Union process.
On a Linux server, just issue "kill -9 12345" (replace 12345 with the process id for the java process running Union).

(or maybe that's what you meant by 'reboot server')

[Toby]

Since the Adobe documentation says you can put explicit IP addresses, I tried that, and it works!

Here is what I have in my policy.xml file:

<cross-domain-policy>
<allow-access-from domain="*" to-ports="80,443,9100" />
<allow-access-from domain="xxx.xxx.xxx.xxx" to-ports="80,443,9100,9110" />
</cross-domain-policy>

(where xxx.xxx is my own IP address) (9100 is the regular gateway, 9110 is the admin gateway)

In addition to that, I have

 <access_control_allow_origin>*</access_control_allow_origin>
for my non-admin gateways as well, which might be overkill.

[Toby]

Well this is weird.

I have two servers running two different Union Apps.

With one of them, I could put the "<allow-access-from domain="My.IP.Address" to-ports="9110" />

and everything was hunky-dory.

With the other one, the stand-alone flash player would fail to connect with that,

but when I put allow-access-from-domain="*" it was ok.

In both cases, using Union Admin from a browser window was fine (with

just that domain in the allow list).

The two servers are on slightly different OSes: first one is Ubuntu 14.

Second one is its close cousin Debian 8.  (The reason for that has to with

a Java-logging-date-time issue, which I have discussed in another thread.)

Other than that, I don't know of any differences between them.

As Chris R said, even without this layer of protection, there is the password,

and at such time as a browser version doesn't work, I'll have to rely on that.

[Toby]

Another in my series of "Stream of Consciousness" posts ... Mystery Is Solved!

The problem was .... (wait for it) .... my policy.xml was uploaded to my server

from my Windows PC in DOS format (CR-LF line delimiters instead of just LF)!

When I changed that, I could use the standalone flash player to connect.

Is that bizarre, or what?

[Toby]

Most of Union Admin works from the Stand Alone player - but not all of it.

Here are two screen shots.  First the web version:

Now the Stand Alone version:

As you can see - the top half of the server page is blank.

There are other differences as well:

Gateway page: Standalone version fails to load policy file to show.

The ping for the Standalone version (they are running side by side) is about double the web version.

Clients and Rooms tabs both seem to function normally in both cases.

Strange, huh?

User agent indicates same Flash Player version.

Flash Player WIN 32,0,0,293 StandAlone (debug, localWithNetwork); 2.1.1 (Build 1302)

Flash Player WIN 32,0,0,293 PlugIn(remote); 2.1.1 (Build 1302)