I Unity 3.0, den webplayer implementerer en sikkerhetsmodell svært lik Den som brukes Av Adobe Flash player™. Disse sikkerhetsrestriksjonene gjelder bare for webplayer og redigeringsprogrammet når Det aktive byggemålet Er WebPlayer. Sikkerhetsmodellen har flere deler:
- Restriksjoner pa tilgang til data pa et annet domene enn det som er vert for din .unity3d fil.
- noen begrensninger på Bruken av Stikkontaktene.
- Ikke Tillate påkalling av noen metode vi vurderte utenfor grenser. (ting Som Fil.Slett, etc).
- Tillater Ikke Bruk Av Systemet.Refleksjon.* for å ringe private / interne metoder i klasser skrev du ikke deg selv.
foreløpig bare de to første delene av sikkerhetsmodellen er emulert I Redaktøren.
den innebygde muti-player nettverksfunksjonaliteten Til Unity (UnityEngine.Network, UnityEngine.NetworkView klasser etc) påvirkes ikke.
dette dokumentet beskriver hvordan du sørger for at innholdet ditt fortsetter å fungere med versjon 3.0 Av Unity webplayer.
- Se Unity API-referansen for informasjon om WWW-klassen.
- Se. NET API-referansen for informasjon om.NET Socket-klassen.
WWW-klassen og sockets bruker det samme policyskjemaet, men i tillegg er de helt separate systemer. WWW-policyen definerer bare tillatelser på webtjenesten der policyen er vert, men socket-policyer gjelder for ALLE tcp / UDP socket-tilkoblinger.
Unity editor kommer med en» Emulate Web Security » – funksjon, som pålegger webplayerens sikkerhetsmodell.Dette gjør det enkelt å oppdage problemer fra redaktørens komfort. Du finner denne innstillingen inEdit – >Prosjektinnstillinger – >Editor. Se Også Redigeringsinnstillingene.
Unity webplayer forventer at en http servert policyfil kalt crossdomain.xml skal være tilgjengelig på domenet du vil ha tilgang til MED WWW-klassen, (selv om dette ikke er nødvendig hvis det er det samme domenet som er vert for unity3d-filen).
tenk deg for eksempel et tetris-spill, vert på følgende url:
http://gamecompany.com/games/tetris.unity3d
trenger å få tilgang til en highscore liste fra følgende url:
http://highscoreprovider.net/gethighscore.php
I dette tilfellet må du plassere en crossdomain.xml – fil ved roten til highscoreprovider.net domene som dette: http://highscoreprovider.net/crossdomain.xml
innholdet i crossdomain.xml – filen er i Formatet Som Brukes Av Flash player. Det er svært sannsynlig at du finner filen crossdomain.xml allerede på plass. Policyen i filen ser slik ut:
<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>når denne filen er plassert på http://highscoreprovider.net/crossdomain.xml, erklærer eieren av det domenet at innholdet i webserveren kan nås av alle webplayer som kommer fra et hvilket som helst domene.
Unity webplayer støtter ikke < tillat-http-forespørsel-overskrifter-fra domene> og < site-kontroll tillatt-kryss-domene-policyer > koder. Merk at crossdomain.xml skal være EN ASCII-fil.
Feilsøking
Innstilling av en miljøvariabel ENABLE_CROSSDOMAIN_LOGGING til 1 vil føre til at konsollmeldinger genereres når Unity-kjøretiden henter og dekoder filen crossdomain.xml. På En Mac kan du angi globale miljøvariabler i /etc/launchd.conf. På EN PC Bruk Kontrollpanel – >System Og Sikkerhet->System->Avanserte systeminnstillinger – >Miljøvariabler…
Her er et eksempel utgang med denne miljøvariabelen sett, når webplayer forsøker å hente et bilde fra en ekstern server:
Determining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgAbout to parse url: http://www.remoteserver.com/image.jpgDetermining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgAbout to parse url: http://www.remoteserver.com/crossdomain.xmlAbout to parse url: http://www.remoteserver.com/image.jpgDetermining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgDownload had OK statuscodeReceived the following crossdomain.xml--------------------------------------<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>----------------------received policyParsing: cross-domain-policycross-domain-policyParsing: allow-access-fromallow-access-from domain: *done parsing policycrossdomain.xml was succesfully parsedAbout to parse url: http://www.remoteserver.com/image.jpgChecking if http://www.remoteserver.com/image.jpg is a valid domainChecking request-host: www.remoteserver.com against valid domain: *All requirements met, the request is approvednår du kjører I Redaktøren, skrives disse meldingene til Redaktøren.logge. Forsøk på å lese en crossdomain.xml – fil som er feil lagret som utf16 med en BOM, vil føre til at xml ikke analyseres:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Expected elementdette skyldes at BOM ikke forventes. Bruk av en ikke-støttet utf16 – fil uten BOM vil resultere i:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Policy can't be constructed from empty stream.Dette skyldes at den første byten i filen er null, noe som får parseren til å tro at den er nådd slutten av filen. Crossdomain.xml må være EN ASCII-fil.
Implikasjoner for Bruk Av Sockets:
En Unity webplayer trenger en socket servert politikk for å koble til en bestemt vert. Denne policyen er som standard vert for målverten på port 843, men den kan også være vert for andre porter. Den funksjonelle forskjellen med en ikke-standardport er at den må hentes manuelt med Sikkerhet.PrefetchSocketPolicy () API-kall, og hvis den ligger på en port høyere enn 1024 policyen kan bare gi tilgang til andre porter høyere enn 1024.
når du bruker standardporten, fungerer det slik: En Unity webplayer prøver å lage EN tcp-kontaktforbindelse til en vert, den kontrollerer først at vertsserveren vil godta connection.It gjør dette ved å åpne EN TCP-kontakt på port 843, utsteder en forespørsel, og forventer å motta en socket-policy over den nye tilkoblingen. Unity webplayer kontrollerer deretter at vertens policy tillater tilkoblingen å fortsette, og den vil fortsette uten feil hvis det er tilfelle. Denne prosessen skjer transparent til brukerens kode, som ikke trenger å endres for å bruke denne sikkerhetsmodellen. Et eksempel på en sokkelpolitikk ser slik ut:
<?xml version="1.0"?><cross-domain-policy> <allow-access-from domain="*" to-ports="1200-1220"/> </cross-domain-policy>"Denne policyen sier effektivt «Innhold fra et hvilket som helst domene er gratis å lage socket-tilkoblinger på ports 1200-1220». Unity webplayer vil respektere dette, og rejectany forsøkt socket tilkobling ved hjelp av en port utenfor dette området (En SecurityException vil bli kastet).
når DU bruker UDP-tilkoblinger, kan policyen også hentes automatisk når de må håndheves på samme måte som MED TCP. Forskjellen er at automatisk henting med TCP skjer når du Kobler til noe (sikrer at DU har lov til å koble til en server), men MED UDP, siden DET er forbindelsesløst, skjer det også når du ringer TIL ET API-punkt som sender eller mottar data (sikrer at du har lov til å sende/motta trafikk til/fra en server).
formatet som brukes for socket-policyen, er Det samme Som Brukes Av Flash player, bortsett fra at noen tagger ikke støttes. Unity webplayer støtter bare » * «som en gyldig verdi for domeneinnstillingen, og innstillingen» to-ports » er obligatorisk.
<?xml version="1.0" encoding="ISO-8859-1"?><!ELEMENT cross-domain-policy (allow-access-from*)><!ELEMENT allow-access-from EMPTY><!ATTLIST allow-access-from domain CDATA #REQUIRED><!ATTLIST allow-access-from to-ports CDATA #REQUIRED>socket-policyen gjelder for både tcp-og UDP-tilkoblingstyper, slik at BÅDE UDP-og TCP-trafikk kan styres av en policyserver.
for enkelhets skyld tilbyr vi et lite program som bare lytter på port 843; når den mottar en forespørselsstreng på en tilkobling, vil den svare med en gyldig socket-policy.Serverkoden finnes i Unity install-mappen, I Data / Tools / SocketPolicyServer På Windows eller / Unity.app / Contents / Tools / SocketPolicyServer PÅ OS X. Merk at pre-bygget kjørbar kan kjøres På Mac siden det er En Mono kjørbar. Bare skriv » mono sockpol.exe » for å kjøre den. Merk at denne eksempelkoden viser riktig oppførsel av en socket policy server. Spesielt forventer serveren å motta en null-terminert streng som inneholder <policy-fil-forespørsel / >. Den sender bare til klienten socket policy xml-dokumentet når denne strengen (og akkurat denne strengen) er mottatt. Videre er det nødvendig at xml header og xml kroppen sendes med en enkelt socket skrive. Bryte hodet og kroppen i separate socket skrive operasjoner kan føre til sikkerhet unntak På Grunn Av Unity mottar en ufullstendig policy. Hvis du opplever problemer med din egen server kan du vurdere å bruke eksempelet som vi gir. Dette skal hjelpe deg med å diagnostisere om du har problemer med serveren eller nettverket.
tredjeparts nettverksbiblioteker, som vanligvis brukes til multiplayer-spillnettverk, skal kunne arbeide med disse kravene så lenge de ikke er avhengige av peer 2 peer-funksjonalitet (se nedenfor), men bruker dedikerte servere. Disse noen ganger også komme ut av boksen med støtte for hosting politikk.
Notat: Mens crossdomain.xml og socket policy-filene er både xml-dokumenter og er stort sett like, er måten disse dokumentene serveres på, svært forskjellige. Crossdomain.xml (som brukes på http-forespørsler) hentes ved hjelp av http på port 80, der-som socket-policyen hentes fra port 843 ved hjelp av en triviell server som implementerer policyen <-fil-forespørsel/>. Du kan ikke bruke en http-server til å utstede socket-policyfilen eller konfigurere en server som bare sender socket-policyfilen som svar på en socket-tilkobling på port 843. Merk også at hver server du kobler til krever sin egen socket policy server.
Feilsøking
du kan bruke telnet til å koble til socket policy-serveren. Et eksempel sesjon er vist nedenfor:
host$ telnet localhost 843Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.<policy-file-request/><?xml version='1.0'?><cross-domain-policy> <allow-access-from domain="*" to-ports="*" /></cross-domain-policy>Connection closed by foreign host.host$i denne eksempeløkten brukes telnet til å koble til localhost på port 843. Telnet svarer med de tre første linjene, og sitter deretter og venter på at brukeren skal skrive inn noe. Brukeren har angitt policyforespørselsstrengen < policy-file-request / >, som socket policy server mottar og svarer med socket policy. Serveren kobler deretter forårsaker telnet å rapportere at tilkoblingen er lukket.
Lyttekontakter
du kan ikke opprette lyttekontakter i webspilleren, den kan ikke fungere som en server. Derfor webplayers kan ikke kommunisere med hverandre direkte (peer 2 peer). NÅR DU bruker TCP-kontakter, kan du bare koble til eksterne endepunkter forutsatt at det er tillatt gjennom socket policy-systemet. FOR UDP fungerer det samme, men konseptet er litt annerledes da det er en forbindelsesløs protokoll, du trenger ikke å koble til / lytte for å sende / motta pakker. Det fungerer ved å håndheve at du bare kan motta pakker fra en server hvis han har svart først med en gyldig policy med allow-access-from domain – taggen.
Dette er bare så irriterende, hvorfor eksisterer alle disse tingene?
sikkerhetsfunksjonene for stikkontakter og WWW finnes for å beskytte folk som installerer Unity Web Player. Uten disse restriksjonene ville et angrep som følgende være mulig:
- Bob jobber i det hvite hus.
- Frank er ond. Han skriver en enhet webgame som later til å være et spill, men i bakgrunnen gjør EN WWW forespørsel til http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. intern.whitehouse.gov er en server som ikke kan nås fra internett, men kan nås Fra Bobs arbeidsstasjon fordi han jobber i det hvite hus.
- Frank sender disse pdf byte til http://frank.com/secretDataUploader.php
- Frank plasserer dette spillet på http://www.frank.com/coolgame.unity3d
- Frank liksom overbeviser Bob å spille spillet.
- Bob spiller spillet.
- Spillet lydløst laster ned hemmelig dokument, og sender Den Til Frank.
MED WWW og socket sikkerhetsfunksjoner, dette angrepet vil mislykkes, fordi før du laster ned pdf, unity sjekker http://internal.whitehouse.gov/crossdomain.xml, med den hensikt å be om at serveren: «er dataene du har på serveren din tilgjengelig for offentlig bruk?». Plassere et crossdomain.xml på en webserver kan ses som svaret på det spørsmålet. I tilfelle av dette eksemplet, systemoperatøren av internal.whitehouse.gov vil ikke plassere et crossdomain.xml på serveren, som vil føre Unity til ikke å laste ned pdf-filen.
Dessverre, for å beskytte de som installerer Unity Web Player, må folk som utvikler Seg I Unity ta hensyn til disse sikkerhetstiltakene når de utvikler innhold. De samme begrensningene er tilstede i alle store plugin-teknologier. (Flash, Silverlight, Shockwave)
Unntak
for å finne den rette balansen mellom å beskytte Web Player-brukere og gjøre livet til innholdsutviklere enkelt, har vi implementert et unntak fra sikkerhetsmekanismen beskrevet ovenfor:
du har lov til å laste ned bilder fra servere som ikke har et kryssdomene.xml-fil. Men det eneste du har lov til å gjøre med disse bildene, er å bruke dem som teksturer i scenen din. Du har ikke lov til å bruke GetPixel () på dem. Du har heller ikke lov til å lese tilbake fra skjermen. Begge forsøkene vil resultere i En SecurityException blir kastet:
SecurityException: No read access to the texture data: at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixel (int,int)begrunnelsen er her er at det er greit å laste ned bildet, så lenge innholdsutvikleren ikke får tilgang til det. Så du kan vise den til brukeren, men du kan ikke sende byte av bildet tilbake til en annen server. Hvis du trenger tilgang til pikseldataene, plasserer du en crossdomain.xml – fil på serveren der bildene hentes fra.