-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unity.iOS SSL doesn't work #523
Comments
Oh that would be cool if so, I'll re-check things once the patch comes out. |
I will also do so, but if it still doesn't work then I will probably have to go back and file another Unity bug...>< |
Well I tried it out with Unity's 5.2.2.p3 version, and it still is broken. I decided to do a little more investigation and discovered that with the d101ce3 commit, it's actually not just SSL it's regular http as well that doesn't work in iOS. I decided to roll back and double check that to see if the 5.2.2p3 version fixed the SSL issue before that commit, but looks like SSL doesn't work there either (although this is for all the platforms I tried not just iOS) non-ssl though seems to work fine in all the platforms. I was curious what exactly the thing was that was fixing the SSL for the other Unity platforms and discovered it's really just the commits in the Rackspace sub repo that are fixing the SSL in the other platforms (and also breaking all communication with iOS). So at this commit of the subrepo, http works for all platforms I tried (osx, android, ios), SSL though for none. At this commit, http/SSL works for (android, osx) but on iOS neither SSL or HTTP works. |
I am aware of this issue, but thanks a lot for your investigation! At least you have given me comfort that it works on non-iOS platforms. As for iOS, I am not quite sure what is going on yet but I have a hunch at the moment. You are not the only user to be affected by this issue so until it is fixed I have a feeling I am going to be focusing on this. |
@z000z I've been able to fix this issue locally, so give the issue/523 branch a shot and see if it works for you. |
I checked it out, it looks like it's communicating with or without SSL, but there seems to be a new problem. For some reason it only pulled one of the documents down from the gateway instead of all of them it should have in iOS, other platforms seemed fine. I did some experimentation and it seems to pickup any new documents I create while the app is running, but any I create while the app is not running it doesn't pick up when the app runs the next time. |
I think it may have to do somehow with me using the session cookies for the replicators, noticed that I was getting these exceptions stacks after a bit:
|
I've seen stuff related to that without using cookies before so I don't think the cookies are necessarily related. The problem is that Unity iOS is choking horribly on Task related stuff. There is also a bug in Sync Gateway at the moment relating to changes, I'll ask if that has any relation. |
Alright, I changed things up a bit to be as non-blocking as possible and after implementing your PRs for issue 506 I was able to replicate with an endpoint using cookies. Let me know how things go this time around in issue/523 |
Cool, that looks like that fixed that previous exception but it looks like I'm still getting some odd behavior and a new exception now. These steps seem to cause it for me:
Wait a bit and this error eventually shows up
|
That's the exact procedure I use for test, pretty much. I have a pre-created Sync Gateway bucket that I download fresh and I am not seeing those issues at the moment. I'll keep trying to see if I get them. |
I'll see if I can make reproduction case from the sample unity project in the repo as well. |
Well I figured out that for some reason my dlls I'm creating aren't the same as the ones in the sample UnityDemo project, if I use the dlls in there it seems to fix my problem. I've got a reproduction Unity project now that demonstrates the problem, although it looks like if I can figure out how to build the dlls in the same way you are it'll fix it. All I'm doing is using Xamarin Studio 5.9.8 and building the Couchbase.Lite.Unity.cbproj and then grabbing the dlls from the bin/Debug/Assets/Plugins For some reason some of my dlls binary match the ones in that UnityDemo, but these are all binary different: It seems the one in particular that's causing the problem for me is the System.Threading.Tasks.Net35.dll, if I replace my generated one with the one from the UnityDemo/Plugins folder the problem goes away. |
Sounds like you forgot to update the hit sub modules. |
That's what I thought too, but as far as I can tell it's all matching up here's the commits I'm using: System.Threading.Tasks.Net35: 35c006b Does that look right to you? If so I wonder if there's maybe some sort of difference in my build environment causing something weird, like xamarin studio vs visual studio, or some sort of mono sdk problem? |
I'll check when I get back. I'm on a crowded train ATM |
Well those are all the correct commits. I tried rebuilding and sure enough the binaries differed for me too, so the next order of business is for me to figure out how in the world I created the good ones. I tried going back a commit or two but so far no luck...very strange. I wonder what else could have changed. |
I found the source of the discrepancy. JSON.NET was still referencing the non-Unity TPL backport which uses async / await (which fails on Unity iOS). I guess it was a crap shoot as to which one got copied to the output. I've corrected the reference and while doing that I also eliminated the Rackspace.Threading namespace all together. At a later point I will restructure the submodules and this will eliminate one layer. |
Ah that makes sense, will be nice to have the stack a little simpler. |
When I was trying to compile the changes I ran into one issue, the System.Net.Http.Unity.csproj was changed to reference:
But I don't have that path, I had to change it to this:
I double checked by re-cloning the repository, possibly the System.Threading.Tasks folder didn't make it into the repo? I just saw you made a similar change to the Couchbase.Lite.Unity.sln, thought I'd mention that one I found as well. |
Sorry about that, it was something I forgot to back out. I backed it out On Mon, Nov 16, 2015 at 10:55 AM, z000z [email protected] wrote:
|
Oh ok cool no problem |
I've forgotten the status of this. We have another user with a similar problem and theirs is not resolved yet, but have the changes here resolved yours? |
Yup it's all resolved for me. |
I tried switching my sync gateway over to SSL but it looks like that doesn't work for the iOS builds. It didn't work for any builds at first for me but I merged the recent commit into my local version:
d101ce3
And that seems to have fixed at least the OSX in editor SSL issues. I believe the problem is that Unity's version of HttpWebRequest while using the .net 2.0 (non subset) just doesn't function with SSL on iOS. If this is the correct observation, the only thing I can think of to get around this would be either to make couchbase lite .net usable with the .net 2.0 subset (seems this is probably unlikely since this looks to be a pretty large change), or possibly to move the HttpWebRequest usages behind an interface and replace that with possibly a Unity.WWW class usage.
The text was updated successfully, but these errors were encountered: