can I force the webMoviePlayer to use the flash player?

The reason I ask is that Safari refuses to play movie content if you’re serving over a self-signed certificate. The movie player works fine on an unencrypted connection, but I need to support a self signed certificate for a stand alone web app. (well… it doesn’t actually work fine, changing URL’s is shaky at best I am currently embedding the movie player into the page via a container control and re-creating it every time you want to change the URL to make autoplay actually play, but thats a separate discussion.)

The SSL connection works for both firefox and chrome but on Safari it just refuses to play with no errors or anything, the movie player just shows “loading” but loads nothing. The link is valid and if you save it to disk you can open it but the browser will not render it through a self-signed cert.

I’m wishing to experiment with forcing safari to use the flash player under those circumstances but I don’t see any actual setting for such a thing. I would be happy to issue a completely unsupported, unsafe, potentially world ending executeJavascript command to it just for testing :wink: Just to see if it would actually work, and then put in an official feature request for such a thing at a later date :wink:

This won’t solve the problem on mobile safari though, I suspect I’ll have to just tell users that they can’t view archived videos on a mobile safari without paying for a real cert. If I could force it to work on Safari in the meantime I’d be happy.

Why not instead simply go for a $30 a year certificate on your server ? Already, Apple decided that all apps connections should be https, soon enough this will be enforced for Safari.

Where are you seeing them for $30? I see free ones, but even the current godaddy sale is for $70. The install is non-trivial and you then need an intermediate cert that you can point to the parent authority so more install. In my case this is for a stand alone server that people run on a dyndns DNS server just for their own connections. So the IP address will change periodically when their cable company resets the DHCP reservation. Am I wrong in thinking that the IP is built into these somehow and will require you to rebuild everything every time the cable company hiccups?

Certs are definitely designed for you setting up a site to take credit cards from a static IP. I want to be able to have non-sniffable traffic to a dyndns site, thats all.

Well, I don’t know about GoDaddy, but 1701 was that price. With Directnic it is $42. In both cases, the certificate has been installed for me. I never the host-at-home option.

The thing with Apple is that they start with strongly recommending iOS 9 apps to use https only (see and may reject apps that have no good reason to use exception. Soon enough that will be mandatory for all apps, including Safari.

When that comes, you may be forced to get SSL.

This is a MacOS X app that is serving a web page to various mobile or just regular web servers. I do plan to replace, or at least augment the web interface to the app with an actual iOS app. I have started on that several times but the iOS framework is not quite up to speed for me yet, I can’t port my data transfer classes yet without completely re-writing them because of the inability of a memory block backed binary stream to automatically expand itself as you write to it, but thats another post :wink: At that point I will be making a direct socket connection from the iOS app to the macOS app and I do understand that is coming too.

I’m a little concerned about that and the requirement for SSL if it requires a signed certificate. There is no central “server” in this case, the server is your own mac. Purchasing a single signed certificate for a server app is one thing and not that horrible, requiring that every user of our software also purchase a signed certificate is not acceptable. I need to be able to provide a safe connection to them without having to spend that extra money and go through a lengthy and painful install process which it will be no matter how much I automate it.

The security improvement when talking from my app to my own program would be negligible anyway. The fist time you connect to your server with the self signed certificate you’ll get that nice warning from the system that this cert is not trusted and do you want to trust it. You say yes that you do. Now if someone was running a man in the middle attack they would not have my certificate, they would have another certificate, so iOS would ask me if I wanted to trust it again. If that message pops up when connecting to your own server remotely then you know you’re being messed with. If it doesn’t then the man in the middle is using a signed certificate, which can’t be signed to your DNS address so that will cause an error popup, or they are using a non-signed cert that will popup the other message. I don’t believe that there is a way to do this that doesn’t cause a message from the OS saying that the cert is either invalid because the DNS name doesn’t match or that it’s a new cert that you need to decide to trust. So there is no benefit to this sort of connection from a signed certificate anyway as I currently understand such things.

It’s doubly strange to me that iOS and Safari would limit only movie files to signed certs, but accept all other kinds of web traffic. The web sites operate just fine over the self signed cert, only serving up movie files causes this issue.

While I would prefer to use the built in flash player that is already in my xojo app by just checking if the client is safari and the connection is secure and then turning on moviePlayer1.useFlash = true or something, since there doesn’t seem to be much interest in that at the moment I’m experimenting with using open source or third party players. Most of the ones I’ve seen so far have so many dependencies that I’m unable to get them to work from an HTTPS connection anyway. But I only wasted an hour or so yesterday looking into that so I haven’t experimented with them all yet. There are several open source ones that look pretty good and would do all that I need to do. I would wrap them into a WebAPI control fairly easily if I can just embed all the dependencies into the app itself for serving rather than getting them from somewhere else.

Back to SSL I’m looking at the “letsencrypt” folks which do it for free. There is a command line tool you can install with Brew that will do the creation of the signed certificate and even the install of it for you into known server types. It will also do a standalone server creation that just leaves you the files for your own setup which is what I would have to do for a standalone xojo web app. If the binary could be included in my program I could use their service probably. The install process would require that any port 80 server my users were running be shut down so that it can temporarily start one and verify that your dyndns name actually resolves to the server you’re trying to create a certificate for. But I could automate that process as I currently automate the creation of the self signed certificate for them, just enter the dyndns name and click create and all the connections can then use the cert. If their license is such that I can’t do that then I would have to tell my users that they need to install brew and this one command line tool through it and just ugh, I might be able to get away with that for those that wanted a signed cert for their own security, but I can’t make that a requirement of just running the app at all if iOS and OSX require a signed cert someday completely. I would have to switch to a server based ipsec tunnel passthrough system where the https signed cert was installed on my servers and then forward the data back and forth to the clients that way. Thats how a lot of other systems like ours actually function, but one of our “things” is that we don’t rely on any cloud connection, you can manage it all yourself. I’m impressed by the number of folks that prefer a dyndns address to their own system as opposed to going through the cloud. That may not be possible in the future if Apple really does shut out any other kinds of encryption and requires what they consider a “valid” signed certificate. Perhaps we could become our own dyndns host for our users and run our own intermediate certificate hosting system. That would require that the users install an intermediate certificate into their keychains, but that would be less of a burden than some of these options. But again, I would have to become a cloud service and I really just don’t want to do that if there are any other options.

But all that worry and concern is for the future, right now I want to be able to serve up movies to web clients on just the regular MacOS browser through an https connection on a self signed certificate. I can’t do that with HTML5 video, but I MIGHT be able to do it with the flash player. I am going to see if I can make Safari send an alternate browser identification string in a moment and make the xojo app think it needs the flash player just to see if that even works. That didn’t occur to me yesterday, but I might be able to see if it’s worth the effort easily that way.

TL:DR i know :wink: but this is such a pain in the neck and I can’t figure out what we gain by having to go through such acrobatics.

and the experiment of just changing the user agent does not fool a xojo app into using the flash player. I believe the decision is made in javascript on the client. I’m going to hack those javascript files in the debugger and make that check return false for supports html5 video and see what happens then :wink:

Keep in mind that flash isn’t enabled by default on safari, and doesn’t work at all on iOS. It may be better to just deal with the cert in the long run.

I can’t quite force it to load for a test anyway, don’t worry I would never have shipped anything that way i just wanted to see if it was even worth while to put in a feature request. I just get a “movie failed to load” message in the contextual menu for the flash object, I think it’s actually failing to load the player source and not my movie that I want it to load. There must be other javascript hooks that I would have to hit to get things to work.

as far as “dealing with the cert” I’m not sure I have a good idea of how to do that in any case. I should tell my users that the yearly purchase of a potentially very expensive signed cert is the only solution to having a secure connection and some day the only solution to making any connection back to the software running on their own computer at all?

That doesn’t seem like a valid solution at all. There has got to be a better solution for this than all these acrobatics. This is just silly.

Something to consider though. Using a self-signed certificate opens you and your users to man in the middle attacks because they’re not signed by a recognized authority. If you truly have a product worth protecting with ssl, then paying $30/yr is pittance.

Go look at Their essential ssl cert will probably do everything you need. Heck, you may be able to use their PositiveSSL product and that one is $10/yr.

[quote=285527:@Greg O’Lone]Something to consider though. Using a self-signed certificate opens you and your users to man in the middle attacks because they’re not signed by a recognized authority. If you truly have a product worth protecting with ssl, then paying $30/yr is pittance.

Go look at Their essential ssl cert will probably do everything you need. Heck, you may be able to use their PositiveSSL product and that one is $10/yr.[/quote]

That IS true if we’re connecting to the server from a computer that you’ve never used before, like at the library or something. It’s not true if you’re connecting from your own iPhone though. A man in the middle attack will cause the “you’ve not trusted this certificate before” to be displayed letting you know that you’re not connecting to a known certificate even if the name and other things match. So as long as you’re connecting to the server from one of your own machines that has already trusted the cert you will know if this happens. It’s not an ideal solution I realize and one does want to be able to connect from other machines with some safety, but it’s not at all useless or dangerous under the normal usage conditions of this product and knowing that limitation.

I will look up that other service and see if they offer a better or simpler to setup SSL that can be imported into the standalone web app. Thanks. is offering $0 certificates. Hard to complain about that price.

Price is really not the issue. It’s that you can’t actually make one work on a dynamic IP address. You have to be running a regular web server on port 80 or have a mail server running on the same domain so that they can send you an email or retrieve a file from the server to figure out if you’re really are who you say you are. In this case the web app runs on a high port and is a remote control interface for the main app. It’s passed through the NAT router. There are no other services running on the machine and the user probably doesn’t have apache turned on in OSX and wouldn’t know where to put the files anyway and there certainly won’t be a mail server running on it.

It is a non-trivial exercise to get a verifiable certificate when it’s not a standard old school server with a server admin who knows where everything is.

And then when your IP changes the cert will no longer match and Safari will start throwing up errors again. So you’ll have to do it all over again. A static IP address cannot be a requirement to use the software :wink:

I do not understand what is gained from a security standpoint if all the rest of your page loads fine through the self signed cert, but that multi-media files refuse to do so without any error message or other indication as to why it’s not working.

Well as an alternative I suggest cloudflare as CDN. Their basic service is free and they offer certs for free too. Of course this works only for cache-able, server-based sites and not for webapps or local-based files in your case.

Since I happen to see this ancient thread in my last search I’ll update it with the answer. It actually has nothing to do with the security certificates at all. It has to do with the fact that the webFile implementation in the WE does not support the Range header. Safari absolutely refuses to load any media content from a server that does not support the Range header. You can add this to a standalone app by managing it yourself in the handleURL or handleSpecialURL events and then it works.

Yes, I know, you shouldn’t actually serve up large media files through the app itself anyway, but sometimes there is no reasonable choice, not every web app is running on a nice server farm somewhere, sometimes they are part of an app themselves running on a regular machine and must do all their own serving.