IFrame და მშობლიური კონტეინერები: როდის უნდა აირჩიოთ რა
სტატიის სრული ტექსტი
1) ტერმინები და კონტექსტი
iFrame - HTML კონტეინერი, რომელიც აერთიანებს მესამე მხარის შინაარსს (თამაში, სალარო, ვიჯეტი). მასპინძელი და შინაარსი ლოგიკურად იზოლირებულია წარმოშობის პოლიტიკით (same-origin პოლიტიკა).
National კონტეინერი არის პროგრამა/მოდული, სადაც ვებ შინაარსი იწყება WebView (WKWebView, Android WebView) ან შეიცვალა მშობლიური SDK (rander, ქსელური, გადახდები, ტელემეტრია).
სადაც გვხვდება: თამაშების დაწყება და დემო, ლობი, სალარო/ონბორდი, ცოცხალი ვიდეო, ჯეკპოტი-ვიჯეტები, პარტნიორი ლანდინგი.
2) მოკლე პასუხი: რა უნდა აირჩიოს
ჩვენ გვჭირდება სწრაფი გაშვება, მრავალი მესამე მხარის შინაარსი, მინიმალური განვითარება iFrame.
ჩვენ გვჭირდება ოფლაინი/დაბალი შეფერხება/მძიმე გრაფიკა/ღრმა ინტეგრაცია მოწყობილობასთან - მშობლიური კონტეინერი (WebView + bridge ან SDK).
ბაზრები/storanalitics/მკაცრი hidlines (Apple/Google), სისტემის გადახდები, მკაცრი RG huks და მშობლიური კონტეინერი.
მედია, SEO landings, მიმოხილვები playable ჩანართებით - iFrame.
3) არჩევანის მატრიცა (გამარტივებული)
4) iFrame: როდის არის ეს იდეალური
სკრიპტები: დემო თამაშების სწრაფი დასკვნა, პარტნიორობის ჩანართები, ჯეკპოტის/რეიტინგის ვიჯეტები, playable ბლოკების ლენდინგი, B2B აგრეგატორები.
დადებითი
ინტეგრაციის სიჩქარე: ერთი 'src' + გასაღებები/პარამეტრები.
მასპინძლის (SOP) სტუმრის მკაცრი იზოლაცია ნაკლები გაჟონვის რისკია.
პროვაიდერის დამოუკიდებელი გამოშვებები (არ ეხება თქვენს ძაფს).
იაფია ასობით პროვაიდერის მასშტაბირება.
უარყოფითი მხარეები
მოწყობილობასთან შეზღუდული ინტეგრაცია და მშობლიური გადახდები.
უფრო რთულია ღრმა ტელემეტრია (უფრო მეტი „ხიდი“).
პრობლემები 3RD Cookies/Storage (Safari/Firefox/ITP).
რთული სრული ეკრანის/ჟესტების/კლავიატურის მობილური.
საუკეთესო პრაქტიკა
'sandbox' ატრიბუტები (შეზღუდეთ 'allow-forms', 'allow-scripts', წერტილოვანი გახსნა 'allow-popups-to-escape-sandbox' საჭიროებისამებრ).
'შინაარსი-უსაფრთხოება-პოლიტიკა "პროვაიდერების თეთრი სიებით;' X-Frame-Options 'მგრძნობიარე გვერდებისთვის.
კომუნიკაცია - 'postMessemssa', 'ღონისძიების შემოწმებით. origin 'და შეტყობინებების სქემა.
Resize: 'ResizeObserver' ivent + 'postMessemass- ის შიგნით (' height ')' მასპინძელი ცვლის 'iframe. style. height`.
საცავი - Storage API/Follbacks; სახელმწიფო - URL პარამეტრების ან წვეულების სახელმწიფო მეშვეობით.
RG/AML: გაჩერების სიგნალები (თვითკონტროლი, ლიმიტები) - მოვლენების საშუალებით, iframe ვალდებულია სხდომის დასრულება.
5) მშობლიური კონტეინერები: როდესაც ისინი გაიმარჯვებენ
სკრიპტები: მობილური პროგრამები ცოცხალი თამაშებითა და სალაროებით, რთული ონბორდი/KUS, ნამდვილი დრო ნაკადები დაბალი შეფერხებით, ოფლაინ რეჟიმში, დასუფთავების გადასახადები, AR/VR ფიჩები.
დადებითი
პროდუქტიულობა/დაბალი ლატენტობა, რკინის წვდომა (კამერა, ბიომეტრია).
ერთი UX და RG/AML ღრმა ინტეგრაცია (სისტემური ალერტები, მშობლიური იარაღი).
საიმედო in-app გადახდები და გამოწერა (StoreKit/Billing).
ზუსტი ტელემეტრია და გაუმართაობის კონტროლი (crashlytics, traces).
უარყოფითი მხარეები
საკუთრების ფასი: მრავალ პლატფორმის განვითარება, გამოშვებები სვეტის საშუალებით.
Apple/Google- ის დამტკიცება; შეზღუდვები აღგზნებულ/გადახდაზე.
მეტი პასუხისმგებლობა უსაფრთხოებისა და კონფიდენციალურობის შესახებ.
ნიმუშები
WebView + JS bridge (ორმხრივი არხი): თამაშის/გადახდების/შეზღუდვების მოვლენები მიმდინარეობს.
ჰიბრიდი: კრიტიკული ნეიტრალური ეკრანები (სალარო, KYC, RG), შინაარსის ეკრანები - WebView/iFrame.
SDK პროვაიდერი: თამაშები/ნაკადები აღჭურვილია ბიბლიოთეკით; მასპინძლობს ნიშნებს, ლიმიტებს, საფულეს.
6) კომუნიკაცია: iFrame მასპინძელი და WebView
ვებ (iFrame):- `window. postMessage({type, payload}, targetOrigin)`
- მოვლენების სქემა: 'game. session. start/stop`, `bet. place/settle`, `rg. limit. hit`, `jackpot. contribution`, `error`.
- შესაბამისობა: შეამოწმეთ 'origin', შემოიტანეთ ვერსია ('v1', 'v2').
- iOS: `WKScriptMessageHandler`; Android: 'addJavascriptInterface' (@ JavascriptInterface- ით, ზედმეტი გამოფენის გარეშე).
- ფორმატი იგივეა ('ტიპი', 'payload', 'trace _ id'), HMAC ხელმოწერები კრიტიკული გუნდებისთვის.
7) უსაფრთხოება და შესაბამისობა
CSP, sandbox, SRI ასეტებისთვის; გამორთეთ 'allow-top-navigation-by-user-action' საჭიროების გარეშე.
Zero-trust მასპინძელსა და შინაარსს შორის: მინიმალური პერმიშენი, საშიში API.
PII/რეზიდენტობა: საცავი და ლოგოები რეგიონების მიხედვით; ჯვარედინი რეგიონალური მოთხოვნების აკრძალვა.
RG/AML: სინქრონული გაჩერების სიგნალები კურსზე; Log WORM Critions.
Cookies/ITP: გამოიყენეთ 'SameSite = None; Secure`; для 3rd-party — Storage Access API или server-side session.
8) პროდუქტიულობა და UX
iFrame: ზარმაცი კავშირი ('loading = lazy'), ქსელის რესურსების პრიორიტეტი, 'preconnect' პროვაიდერის დომენებზე.
WebView: გამორთეთ ზედმეტი JS, გადაიღეთ ასეტები, ჩართეთ აპარატურა აჩქარება, აკონტროლეთ GC/მეხსიერება.
ფულადი სკრინი და ორიენტაცია: მკაცრად განსაზღვრეთ ღონისძიების სქემა (როდის და ვინ იწყებს გადასვლას).
შეცდომების დამუშავება: ერთიანი კოდები ('ქსელი _ TIMEOUT', 'PAYMENT _ BLOCKED', 'RG _ BLOCK') და UX ინდუსტრიები.
9) ანალიტიკა და A/B
ღონისძიების საბურავი: 'სესია. started/ended`, `bet. placed/settled`, `deposit. succeeded`, `rg. limit. hit`, `error`.
იდენტიფიკატორები: 'tenant _ id/brand _ id/region/player _ pseudo', 'trace _ id'.
IFrame- ში - სიმღერა parent-proxy- ის მეშვეობით (მასპინძელი მენეჯერი), WebView- ში - მშობლიური SDK ანალიტიკოსები.
A/B: ფიჩფლაგები მასპინძელში; iFrame შეიტყობს ვარიანტს 'postMessemass- ის საშუალებით (init)'.
10) გადახდების ინტეგრაცია
ვებ/iFrame: სასურველია სალარო მასპინძელში, და არა iFrame- ის შიგნით (ნაკლები 3rd-party საკეტებით, უკეთესია, ვიდრე UX, უფრო ადვილია RG/AML).
Nation: StoreKit/Billing დასაშვები სცენარებისთვის; წინააღმდეგ შემთხვევაში - PSP ორკესტრი არის წარმართული ძლიერი ტელემეტრიითა და იდემპოტენციით.
11) კეისის არჩევანის რუკა
თქვენ ხართ აგრეგატორი/მედია ათასობით თამაშით და მინიმალური dev-რესურსებით:- iFrame, მკაცრი 'sandbox', 'postMessemass- პროტოკოლი, სალარო/ლიმიტები მასპინძელში.
- National კონტეინერი: WebView for lobby, national სალარო/KYC/RG, SDK live პროვაიდერი.
- • სრულფასოვანი SDK ან ძრავა პროგრამაში.
12) ჩეკის ფურცლები
iFrame ინტეგრაცია
- 'sandbox' + მინიმალური 'allow' -prava.
- CSP თეთრი სიებით; SRI სკრიპტებისთვის.
- მკაფიო სქემა 'postMessemassa' (+ ვერსია + 'origin').
- RG/AML გაჩერების სიგნალები მხარდაჭერილია, სესიები სწორად მთავრდება.
- საცავი: გეგმა ITP/3rd-party cookies.
- ტელემეტრია: bets/min, settle-lag, error-rate, FPS (საჭიროების შემთხვევაში).
მშობლიური კონტეინერი
- JS-bridge, რომელსაც აქვს მეთოდების თეთრი სია და payload ტიპიზაცია.
- მშობლიური სალარო/KYC/RG, ფულადი გზების იდენტიფიკაცია.
- იარაღი, deep-links, lifecycle-huks (თამაშის პაუზა ზარის/ფონური მუშაობის დროს).
- Crash/trace, privacy permishens, PII წვდომის აუდიტი.
- Apple/Google პოლიტიკოსები აღფრთოვანებული და გადახდები შეესაბამება.
13) ანტი-ნიმუშები (წითელი დროშები)
IFrame პროვაიდერის შიგნით სალაროს დაყენება (კონტროლის დაკარგვა RG/AML/ტელემეტრიაზე).
რეალობის არარსებობა. origin` в `postMessage`.
3rd-party cookies, როგორც სტატის ერთადერთი გზა.
იგივე გასაღებები/საიდუმლოებები რამდენიმე ბრენდის/რეგიონისთვის.
ვებ ინსპექტორისგან ნაშთების/ლიმიტების სახელმძღვანელო რედაქტირება (სერვერის შემოწმება არ არის).
ნულოვანი დეგრადაცია: iFrame ვარდნა არღვევს მთელ გვერდს graceful-fallback გარეშე.
14) დასკვნა
iFrame - თქვენი „სწრაფი კარიბჭე“ შინაარსის ეკოსისტემაში: მცირე ხარჯები, მკაცრი იზოლაცია, სწრაფი გამოშვებები. მშობლიური კონტეინერები - სიღრმეზე: შესრულება, მოწყობილობა, ნაკადი, მკაცრი RG/AML და ტოპ UX. არა ერთი მიდგომა იმარჯვებს, არამედ კომბინაცია: iFrame/ვებ კატალოგებისა და დემოსთვის, ფულისთვის, ცოცხალი გამოცდილებისა და მარეგულირებელი სიმკაცრისთვის. პასუხისმგებლობის ზონების სწორი გამიჯვნა, მოვლენების მკაფიო კონტრაქტები და ძლიერი უსაფრთხოება მასშტაბს მისცემს კომპრომისის გარეშე სიჩქარის, რისკების და ხარისხის შესახებ.
