koobas.hobune.stream
Cookie Header With WebPlayer Unity3d 4.3
Setting the cookie header with webplayer worked in Unity 4.2 but fails in Unity 4.3.
To replicate
var headers = new Hashtable{{"Cookie", "CookieValue" }};
var www = new WWW("http://google.com", new byte[1], headers);
yield return www;
The error message is
UnityEngine.WWW..ctor (System.String url, System.Byte[] postData, System.Collections.Hashtable headers) (at C:/BuildAgent/work/d3d49558e4d408f4/artifacts/EditorGenerated/Utils.cs:72) I read the change log for 4.3. It had no mention of this change. Not sure what to do, authentication cookies are kinda important to me.ArgumentException: Cannot overwrite header: Cookie
UnityEngine.WWW.CheckSecurityOnHeaders (System.String[] headers) (at C:/BuildAgent/work/d3d49558e4d408f4/Runtime/Export/WWW.cs:67)
I am facing the exact same problem. It seems like ever since Unity 4.3 was released there are many new issues with security checks blocking legitimate actions...
The same code works on other environments (like standalone). However upon switching to web player environment this fails to work.
I have a work around. Dont use Cookies to authenticate. You could use basic authentication for instance - and encode the username and password into a header field.
I ended up injecting my authentication cookie into the header and then augmented my server code to reattach it as a cookie to the request before authentication took place. Kind of an odd solution, but I can reuse all my cookie dependent authentication stuff.
Would you please share your reattachment code pls pls pls. I'm assu$$anonymous$$g php, although maybe not.
I've been coding just enough php to get mysql in shape but I really want to make use of session variables. I'm sure I can get the session id back to my php, but I don't know enough about session handling to pull of "reinstating" the passed back id as the session id for the script that is receiving it.
Did I ask please :)
How to fix this: Clear the generated folders, like library, temp and object.
Steps to replicate the bug and solution:
Install unity 4.2.
Create a new project 'A' using 4.2, note that op's code works.
Upgrade to unity 4.3.
Create a new project 'B' using 4.3, note that again op's code works.
Open and upgrade the 4.2 project 'A' to 4.3, note you get the Exception.
Clear the generated folders in project 'A', note that op's code works.
I guess unity 4.3 has a updated library but does not update/invalidate generated code when it upgrades the projects.
Great to know! It just baffles me why some serialized project data / setting is affecting "CheckSecurityOnHeaders". I smell some global state here :D
ps: To all who wants try this method:
$$anonymous$$ake sure you have a backup of your project
Also you should enable meta files in the settings or deleting the library folder will break your project.
Finally verify you have a working backup ;)
If something goes wrong, don't blame GeorgeCrane ;)
I dont understand your solution. What is this "CheckSecurityOnHeaders" setting ? I looked in project settings and on google and found nothing. I`snt this just a web-player sandbox security issue ?
I was having this problem using GameAnalytics and this method solved it for me. Thanks!
This works for me too, but the error reappears periodically (meaning I then have to clear my Library and Temp directories again to get rid of it). Has anyone come across a proper fix for this?
For anyone else still struggling with this problem:
For me, it seems to only affect the Editor when running with WebPlayer as the build target (which, if your project is a web one, is probably most of the time!). To avoid the problem and get on with your development, simply switch the build target to PC & Mac Standalone, and the issue goes away. When deploying, you then need to simply switch it back - it doesn't seem to affect deployed WebPlayer builds, only in the Editor. Of course, if this does seem to affect your deployed builds, you can always nuke your temporary directories and re-deploy - which at least you'll have to do far less frequently.
I'm posting this as an answer on the grounds that it's arguably a workaround. It's also possibly an explanation for GeorgeCrane's directory-nuking solution above, as one of the files in there stores the current build target - so by deleting them, the build target is reset to Standalone, which then appears to work.
