Safari iframe cookie của bên thứ 3 không còn hoạt động?

137

Vì vậy, đây là lần trả thù thứ mười một của câu hỏi "làm cách nào để cookie của bên thứ 3 hoạt động trong Safari" nhưng tôi lại hỏi vì tôi nghĩ sân chơi đã thay đổi, có lẽ sau tháng 2 năm 2012. Một trong những thủ thuật tiêu chuẩn để có được thứ 3 cookie bên trong Safari như sau: sử dụng một số javascript để POST vào iframe ẩn. Nó (đã từng) lừa Safari nghĩ rằng người dùng đã tương tác với nội dung của bên thứ 3 và sau đó cho phép đặt cookie.

Tôi nghĩ rằng lỗ hổng này đã bị đóng lại sau vụ bê bối nhẹ, nơi nó được tiết lộ rằng Google đã sử dụng mánh khóe đó với quảng cáo của mình. Ít nhất, trong khi sử dụng thủ thuật này, tôi đã hoàn toàn không thể thiết lập cookie trong Safari. Tôi đã khai quật một số bài đăng trên internet ngẫu nhiên tuyên bố rằng Apple đang làm việc để đóng lỗ hổng nhưng tôi không tìm thấy bất kỳ từ chính thức nào.

Là một dự phòng, tôi thậm chí đã thử thiết kế lại khung bên thứ ba chính để bạn phải nhấp vào nút trước khi nội dung được tải nhưng ngay cả mức độ tương tác trực tiếp đó cũng không đủ để làm tan chảy trái tim lạnh lẽo lạnh lẽo của Safari.

Vậy có ai biết chắc chắn liệu Safari có thực sự đóng lỗ hổng này không? Nếu vậy, có cách giải quyết nào khác (ngoài thủ công bao gồm ID phiên trong mỗi yêu cầu) không?

javascript  facebook  iframe  safari 
— gs Hurley
nguồn
21
Sử dụng iframe của bên thứ ba cần cookie chắc chắn không phải là một cuộc tấn công bảo mật! Chúng tôi điều hành một webshop được sử dụng trong iframe trên vô số tên miền khác nhau và có tất cả các loại vấn đề với Safari vào cuối, vì vậy tôi cũng rất quan tâm đến câu trả lời cho câu hỏi (hợp pháp) này.
— mscha
14
Khá nhiều người xây dựng ứng dụng Facebook có vấn đề này với Safari. Các ứng dụng Facebook chạy trong iframe và theo định nghĩa, tất cả đều đến từ bên thứ 3. Đây là lý do tại sao hỗ trợ cho Safari trên các ứng dụng Facebook hơi khó hiểu: bạn không thể sử dụng cookie.
— gs Hurley
Tôi không thể tái tạo vấn đề này trên safari 5.1.7. Nó chấp nhận cookie từ iframe ứng dụng facebook của tôi với cài đặt "không có cookie của bên thứ ba" mặc định. Tuy nhiên, Chrome 19.0.1084.46 với cùng cài đặt sẽ chặn cookie.
— Evgeny Shadchnev
4
Chrome 19+ với tùy chọn "Chặn các cookie và dữ liệu trang web của bên thứ ba" mặc định đã được kiểm tra là / thậm chí khắc nghiệt hơn so với cài đặt "Chặn cookie từ bên thứ ba và nhà quảng cáo" mặc định của Safari. Trong chrome, ngay cả khi bạn truy cập tên miền của bên thứ 3 và đã đặt cookie, chúng sẽ không được truyền đến iframe. Người dùng thực sự phải thêm một "ngoại lệ" cho tên miền của bạn trong cài đặt bảo mật Chrome của mình.
— Aaron Gibralter
Bạn có ý nghĩa gì với tháng 2 năm 2012? Có sự thay đổi kỹ thuật trong Safari hoặc thay đổi luật?
— chất lỏng

Câu trả lời:

51

Chỉ muốn để lại một giải pháp làm việc đơn giản ở đây không yêu cầu tương tác người dùng .

Như tôi đã nói trong một bài tôi đã thực hiện :

Về cơ bản, tất cả những gì bạn cần làm là tải trang của bạn trên top.location, tạo phiên và chuyển hướng nó trở lại facebook.

Thêm mã này vào đầu index.phpvà đặt $page_urlvào tab ứng dụng / URL ứng dụng cuối cùng của bạn và bạn sẽ thấy ứng dụng của mình sẽ hoạt động mà không gặp vấn đề gì.

<?php
    // START SAFARI SESSION FIX
    session_start();
    $page_url = "http://www.facebook.com/pages/.../...?sk=app_...";
    if (isset($_GET["start_session"]))
        die(header("Location:" . $page_url));

    if (!isset($_GET["sid"]))
        die(header("Location:?sid=" . session_id()));
    $sid = session_id();
    if (empty($sid) || $_GET["sid"] != $sid):
?>
   <script>
        top.window.location="?start_session=true";
    </script>
<?php
    endif;
    // END SAFARI SESSION FIX
?>

Lưu ý: Điều này được tạo ra cho facebook, nhưng nó thực sự sẽ hoạt động trong bất kỳ tình huống tương tự nào khác.

Chỉnh sửa ngày 20 tháng 12 năm 2012 - Duy trì yêu cầu đã ký:

Đoạn mã trên không duy trì dữ liệu bài đăng yêu cầu và bạn sẽ mất chữ ký, nếu ứng dụng của bạn phụ thuộc vào yêu cầu đã ký, hãy thử mã sau:

Lưu ý: Điều này vẫn đang được thử nghiệm đúng cách và có thể kém ổn định hơn phiên bản đầu tiên. Sử dụng có nguy cơ của riêng bạn / Phản hồi được đánh giá cao.

(Cảm ơn CBroe đã chỉ cho tôi đi đúng hướng ở đây cho phép cải thiện giải pháp)

// Start Session Fix
session_start();
$page_url = "http://www.facebook.com/pages/.../...?sk=app_...";
if (isset($_GET["start_session"]))
    die(header("Location:" . $page_url));
$sid = session_id();
if (!isset($_GET["sid"]))
{
    if(isset($_POST["signed_request"]))
       $_SESSION["signed_request"] = $_POST["signed_request"];
    die(header("Location:?sid=" . $sid));
}
if (empty($sid) || $_GET["sid"] != $sid)
    die('<script>top.window.location="?start_session=true";</script>');
// End Session Fix
— Diogo Raminhos
nguồn
Cảm ơn bạn, hoạt động như một cơ duyên và rất dễ thực hiện trong các ứng dụng hiện có :-)
— SamiSalami
Vì vậy, cái này về cơ bản hoạt động với một vài chuyển hướng, phải không?
— Aaron Gibralter
1
@hugoderhungrige bạn được chào đón, tôi vừa thêm một phiên bản mới, vui lòng kiểm tra nếu bạn cần duy trì yêu cầu đã ký trên ứng dụng của mình.
— Diogo Raminhos
1
@CBroe Cảm ơn bạn rất nhiều vì đã chỉ ra điều đó! Bạn đã đúng, nó hoạt động, vì yêu cầu thứ hai mà người dùng đã bắt đầu một phiên! Tôi đoán rằng "người mù tồi tệ nhất là người không muốn nhìn thấy".
— Diogo Raminhos
1
@Whiteagle Bạn có thể cung cấp một trường hợp thử nghiệm chứng minh 1 và 2 không?
— Gajus
35

Bạn nói rằng bạn sẵn sàng để người dùng của bạn nhấp vào nút trước khi tải nội dung. Giải pháp của tôi là có một nút mở một cửa sổ trình duyệt mới. Cửa sổ đó đặt cookie cho miền của tôi, làm mới dụng cụ mở và sau đó đóng lại.

Vì vậy, kịch bản chính của bạn có thể trông như:

<?php if(count($_COOKIE) > 0): ?>
<!--Main Content Stuff-->
<?php else: ?>
<a href="/safari_cookie_fix.php" target="_blank">Click here to load content</a>
<?php endif ?>

Sau đó safari_cookie_fix.php trông giống như:

<?php
setcookie("safari_test", "1");
?>
<html>
    <head>
        <title>Safari Fix</title>
        <script type="text/javascript" src="/libraries/prototype.min.js"></script>
    </head>
    <body>
    <script type="text/javascript">
    document.observe('dom:loaded', function(){
        window.opener.location.reload();
        window.close();
    })
    </script>
    This window should close automatically
    </body>
</html>
— drewrichards
nguồn
Tôi đã nghĩ về một cái gì đó như thế. Hoạt động hoàn hảo. Tôi tải nó cùng với hộp thoại cho phép. Cảm ơn!
— vwoelm
Có vẻ như điều này cũng đang làm việc xung quanh các cài đặt của Safari và rằng, một khi kiến ​​thức phổ biến sẽ bị trục trặc giống như các "giải pháp" khác. Tôi đang tìm kiếm một giải pháp hoàn toàn khác, bởi vì nó trở nên khá rõ ràng rằng cookie của bên thứ 3 bây giờ là ma quỷ, ngay cả khi được sử dụng theo những cách thích hợp.
— LocalPCGuy
1
Giải pháp này làm việc cho tôi, tuy nhiên, cửa sổ bật lên có cần thiết không? Bạn có thể chuyển hướng iframe của mình sang trang safari, đặt cookie, sau đó chuyển hướng quay lại trò chơi với các tiêu đề chuyển hướng không? Hoặc bạn cần cửa sổ bật lên để người dùng có một số hình thức liên hệ trực tiếp với máy chủ?
— Anthony Hastings
cái này hoạt động tốt; may mắn thay, việc nhấn nút để khởi tạo điều này không phải là vấn đề lớn trong ứng dụng của tôi.
— littlered
@LocalPCGuy Tôi không chắc chắn rằng nó sẽ bị trục trặc như các giải pháp khác bởi vì nó yêu cầu người dùng thực sự nhấp / tương tác với trang để cửa sổ bật lên không bị chặn. Giải pháp này mà Safari đã đưa ra dường như hoạt động tốt: nhà quảng cáo sẽ không thể bí mật đặt cookie tên miền chéo và các ứng dụng nhúng sẽ yêu cầu người dùng tương tác trước khi có thể đặt cookie.
— Aaron Gibralter
15

Tôi đã lừa Safari bằng .htaccess:

#http://www.w3.org/P3P/validator.html
<IfModule mod_headers.c>
Header set P3P "policyref=\"/w3c/p3p.xml\", CP=\"NOI DSP COR NID CUR ADM DEV OUR BUS\""
Header set Set-Cookie "test_cookie=1"
</IfModule>

Và nó cũng ngừng hoạt động đối với tôi. Tất cả các ứng dụng của tôi đang mất phiên trong Safari và đang chuyển hướng ra khỏi Facebook. Vì tôi đang vội sửa các ứng dụng đó, tôi hiện đang tìm kiếm một giải pháp. Tôi sẽ giữ cho bạn được đăng.

Chỉnh sửa (2012-04-06): Rõ ràng Apple đã "sửa" nó với 5.1.4. Tôi chắc chắn đây là phản ứng của Google: "Đã xảy ra sự cố trong quá trình thực thi chính sách cookie của nó. Các trang web của bên thứ ba có thể đặt cookie nếu tùy chọn" Chặn cookie "trong Safari được đặt thành cài đặt mặc định là" Từ các bên thứ ba và nhà quảng cáo ". Http://support.apple.com/kb/HT5190

— vwoelm
nguồn
1
Rõ ràng Apple đã "sửa" nó với 5.1.4. Tôi chắc chắn đây là phản ứng của Google: "Đã xảy ra sự cố trong quá trình thực thi chính sách cookie của nó. Các trang web của bên thứ ba có thể đặt cookie nếu tùy chọn" Chặn cookie "trong Safari được đặt thành cài đặt mặc định là" từ bên thứ ba và các nhà quảng cáo". support.apple.com/kb/HT5190
— vwoelm
1
Vì vậy, tôi nghĩ rằng nhận xét này của vwoelm là gần nhất với câu trả lời mà tôi đang tìm kiếm. Đầu tiên và quan trọng nhất, tôi muốn xác nhận rằng Apple chắc chắn đã đóng lỗ hổng và tham chiếu đến bài viết hỗ trợ của Apple chỉ có thế. Phần thứ hai của câu hỏi của tôi mặc dù vẫn còn liên quan. Phạm vi của các tùy chọn cho cách giải quyết là gì. Rõ ràng, chúng ta có thể mã hóa ID phiên dưới dạng tham số GET / POST nhưng các tùy chọn khác là gì. Liệu lưu trữ cục bộ làm việc trong bối cảnh này? Flash cookie?
— gs Hurley
@vwoelm: đó thực sự là câu trả lời tôi đang tìm kiếm (nhưng không hy vọng) cho. Nếu bạn đặt câu trả lời này thay vì nhận xét, tôi sẽ chỉ định cho bạn tiền thưởng.
— mscha
3
@gshurley Tôi nghĩ gửi id phiên thông qua các tham số GET / POST là lựa chọn duy nhất. Điều đó không an toàn, nhưng một lần nữa Facebook buộc chúng tôi phải phục vụ các ứng dụng canvas mà không cần SSL. Và bên cạnh những gì bạn thực sự nhận được bằng cách hack một ứng dụng Facebook haha? Chúng tôi đang thương xót Apple và họ hiện đang ở chế độ tàn khốc.
— hekevintran
14

Trong bộ điều khiển Ruby on Rails, bạn có thể sử dụng:

private

before_filter :safari_cookie_fix

def safari_cookie_fix
  user_agent = UserAgent.parse(request.user_agent) # Uses useragent gem!
  if user_agent.browser == 'Safari' # we apply the fix..
    return if session[:safari_cookie_fixed] # it is already fixed.. continue
    if params[:safari_cookie_fix].present? # we should be top window and able to set cookies.. so fix the issue :)
      session[:safari_cookie_fixed] = true
      redirect_to params[:return_to]
    else
      # Redirect the top frame to your server..
      render :text => "<script>alert('start redirect');top.window.location='?safari_cookie_fix=true&return_to=#{set_your_return_url}';</script>"
    end
  end
end
— nói đùa
nguồn
Có một vấn đề tương tự với các phiên trong safari?
— Rails người mới bắt đầu
bạn có thể thay thế set_your_return_url thành request.env ['HTTP_REFERER'] vì chúng tôi đang ở trong iframe :-D
— Luc Boissaye
Tôi đã thử giải pháp này và vấn đề duy nhất là tôi không thể quay lại url iframe chính. Có một phương pháp nào trong Rails để lấy url của iframe cha không? cảm ơn
— idejuan
Tôi đã mất thời gian nhưng cuối cùng tôi đã hiểu ra rằng cách dễ nhất (TMO) là chỉ cần thêm nó dưới dạng tham số chuỗi truy vấn vào url chuyển hướng của ứng dụng rails. Wasy và sạch sẽ.
— Guyaloni 21/07/2015
1
Câu trả lời này tạo ra một chuyển hướng mở, đây là một vấn đề bảo mật phổ biến. Mã nguy hiểm là redirect_to params[:return_to]. Điều đó cần phải được kiểm tra đối với danh sách trắng những nơi an toàn để chuyển hướng đến. Xem owasp.org/index.php/ từ
— phylae
13

Đối với tình huống cụ thể của tôi, tôi đã giải quyết vấn đề bằng cách sử dụng window.postMessage () và loại bỏ mọi tương tác của người dùng. Lưu ý rằng điều này sẽ chỉ hoạt động nếu bạn bằng cách nào đó có thể thực thi js trong cửa sổ cha. Hoặc bằng cách có nó bao gồm một js từ tên miền của bạn hoặc nếu bạn có quyền truy cập trực tiếp vào nguồn.

Trong iframe (domain-b) tôi kiểm tra sự hiện diện của cookie và nếu nó không được đặt sẽ gửi postMessage cho cha mẹ (domain-a). Ví dụ;

if (navigator.userAgent.indexOf('Safari') != -1 && navigator.userAgent.indexOf('Chrome') == -1
    && document.cookie.indexOf("safari_cookie_fix") < 0) {
    window.parent.postMessage(JSON.stringify({ event: "safariCookieFix", data: {} }));
}

Sau đó, trong cửa sổ cha mẹ (tên miền-a) lắng nghe sự kiện.

if (typeof window.addEventListener !== "undefined") {
    window.addEventListener("message", messageReceived, false);
}

function messageReceived (e) {
    var data;

    if (e.origin !== "http://www.domain-b.com") {
        return;
    }

    try {
        data = JSON.parse(e.data);
    }
    catch (err) {
        return;
    }

    if (typeof data !== "object" || typeof data.event !== "string" || typeof data.data === "undefined") {
        return;
    }

    if (data.event === "safariCookieFix") {
        window.location.href = e.origin + "/safari/cookiefix"; // Or whatever your url is
        return;
    }
}

Cuối cùng, trên máy chủ của bạn (http://www.domain-b.com/safari/cookiefix), bạn đặt cookie và chuyển hướng trở lại nơi người dùng đến. Ví dụ dưới đây là sử dụng ASP.NET MVC

public class SafariController : Controller
{
    [HttpGet]
    public ActionResult CookieFix()
    {
        Response.Cookies.Add(new HttpCookie("safari_cookie_fix", "1"));

        return Redirect(Request.UrlReferrer != null ? Request.UrlReferrer.OriginalString : "http://www.domain-a.com/");
    }

}
— Frank
nguồn
Bạn không nhận được lỗi cú pháp với lệnh gọi đến postMessage?
— akousmata
Cần phải thêm một tham số thứ hai "*"để PostMessagesửa chữa các lỗi cú pháp
— Michael Baldry
Ước gì tôi có thể đưa ra câu trả lời này nhiều hơn. Đó là cách đơn giản và đúng đắn nhất để thực sự giải quyết vấn đề này. Cảm ơn bạn đã gửi nó!
— AaronP
9

Tôi đã có cùng một vấn đề và hôm nay tôi đã tìm thấy một bản sửa lỗi phù hợp với tôi. Nếu tác nhân người dùng chứa Safarivà không có cookie nào được đặt, tôi chuyển hướng người dùng đến Hộp thoại OAuth:

<?php if ( ! count($_COOKIE) > 0 && strpos($_SERVER['HTTP_USER_AGENT'], 'Safari')) { ?>
<script type="text/javascript">
    window.top.location.href = 'https://www.facebook.com/dialog/oauth/?client_id=APP_ID&redirect_uri=MY_TAB_URL&scope=SCOPE';
</script>
<?php } ?>

Sau khi xác thực và yêu cầu quyền, Hộp thoại OAuth sẽ chuyển hướng đến URI của tôi ở vị trí trên cùng. Vì vậy, thiết lập cookie là có thể. Đối với tất cả các ứng dụng tab canvas và trang của chúng tôi, tôi đã bao gồm tập lệnh sau:

<script type="text/javascript">
    if (top.location.href==location.href) top.location.href = 'MY_TAB_URL';
</script>

Vì vậy, người dùng sẽ được chuyển hướng một lần nữa vào tab trang Facebook với một cookie hợp lệ đã được đặt và yêu cầu đã ký được đăng lại.

— Galcha
nguồn
Công việc tuyệt vời này Tôi đã cập nhật kiểm tra tác nhân người dùng để đảm bảo Chrome cũng không có trong tác nhân người dùng vì Chrome cũng có Safari trong chuỗi tác nhân người dùng. Chuyển hướng đến trang tên miền của bạn, đặt cookie cần thiết / phiên bắt đầu và sau đó chuyển hướng trở lại ứng dụng của bạn trên apps.facebook.com hoạt động như một cơ duyên. Có vẻ ngớ ngẩn, nhưng hoạt động tốt. Cảm ơn Sascha cho tiền boa!
— Mike
7

Cuối cùng tôi đã tìm ra một giải pháp tương tự với giải pháp mà Sascha cung cấp, tuy nhiên với một chút điều chỉnh, vì tôi đang đặt cookie rõ ràng trong PHP:

// excecute this code if user has not authorized the application yet
// $facebook object must have been created before

$accessToken = $_COOKIE['access_token']

if ( empty($accessToken) && strpos($_SERVER['HTTP_USER_AGENT'], 'Safari') ) {

    $accessToken = $facebook->getAccessToken();
    $redirectUri = 'https://URL_WHERE_APP_IS_LOCATED?access_token=' . $accessToken;

} else {

    $redirectUri = 'https://apps.facebook.com/APP_NAMESPACE/';

}

// generate link to auth dialog
$linkToOauthDialog = $facebook->getLoginUrl(
    array(
        'scope'         =>  SCOPE_PARAMS,
        'redirect_uri'  =>  $redirectUri
    )
);

echo '<script>window.top.location.href="' . $linkToOauthDialog . '";</script>';

Điều này làm là kiểm tra xem cookie có khả dụng khi trình duyệt là safari không. Trong bước tiếp theo, chúng tôi đang ở trong miền ứng dụng, cụ thể là URI được cung cấp dưới dạng URL_WHERE_APP_IS_LOCATED ở trên.

if (isset($_GET['accessToken'])) {

    // cookie has a lifetime of only 10 seconds, so that after
    // authorization it will disappear
    setcookie("access_token", $_GET['accessToken'], 10); 

} else {

  // depending on your application specific requirements
  // redirect, call or execute authorization code again
  // with the cookie now set, this should return FB Graph results

}

Vì vậy, sau khi được chuyển hướng đến miền ứng dụng, cookie được đặt rõ ràng và tôi chuyển hướng người dùng đến quy trình ủy quyền.

Trong trường hợp của tôi (vì tôi đang sử dụng CakePHP nhưng nó sẽ hoạt động tốt với bất kỳ khung MVC nào khác) Tôi đang gọi lại hành động đăng nhập khi ủy quyền FB được thực thi vào lần khác và lần này thành công do cookie hiện có.

Sau khi đã ủy quyền ứng dụng một lần, tôi không gặp vấn đề gì nữa khi sử dụng ứng dụng với Safari (5.1.6)

Hy vọng rằng có thể giúp bất cứ ai.

— Marcel Kalveram
nguồn
1
cái này hiệu quả với tôi !! cảm ơn!! .. tôi đã gặp vấn đề này với Safari 5.1.7 .... bây giờ nó đã được giải quyết!
— Khalizar
5

Tôi gặp vấn đề này trên các thiết bị chạy iOS. Tôi đã tạo một cửa hàng có thể nhúng trong một trang web bình thường bằng cách sử dụng iframe. Bằng cách nào đó, trên mỗi lần tải, người dùng có một phiên mới, dẫn đến việc người dùng bị kẹt giữa chừng vì quá trình này không xuất hiện trong phiên.

Tôi đã thử một số giải pháp được đưa ra trên trang này, nhưng cửa sổ bật lên không hoạt động tốt trên iPad và tôi cần giải pháp minh bạch nhất.

Tôi đã giải quyết nó bằng cách sử dụng một chuyển hướng. Trang web nhúng trang web của tôi trước tiên phải chuyển hướng người dùng đến trang web của tôi, vì vậy, trang web hàng đầu khung chứa url đến trang web của tôi, nơi tôi đặt cookie và chuyển hướng người dùng đến trang thích hợp trên trang web nhúng trang web của tôi, được thông qua thông qua các url.

Mã PHP ví dụ

Trang web từ xa chuyển hướng người dùng đến

http://clientname.example.com/init.php?redir=http://www.domain.com/shop/frame

init.php

<?php
// set a cookie for a year
setcookie('initialized','1',time() + 3600 * 24 * 365, '/', '.domain.com', false, false);
header('location: ' . $_GET['redir']);
die;

Người dùng kết thúc tại http://www.domain.com/shop/framenơi trang web của tôi được nhúng, lưu trữ các phiên như bình thường và ăn cookie.

Hy vọng điều này sẽ giúp được ai đó.

— ar34z
nguồn
3

Hãy để tôi chia sẻ sửa chữa của tôi trong ASP.NET MVC 4. Ý tưởng chính như trong câu trả lời đúng cho PHP. Mã tiếp theo được thêm vào Bố cục chính trong phần tiêu đề gần tập lệnh:

@if (Request.Browser.Browser=="Safari")
{
    string pageUrl = Request.Url.GetLeftPart(UriPartial.Path);
    if (Request.Params["safarifix"] != null && Request.Params["safarifix"] == "doSafariFix")
    {
        Session["IsActiveSession"] = true;
        Response.Redirect(pageUrl);
        Response.End();
    }
        else if(Session["IsActiveSession"]==null)
    {
        <script>top.window.location = "?safarifix=doSafariFix";</script>
    }
}
— Yara
nguồn
3

Giải pháp này áp dụng trong một số trường hợp - nếu có thể:

Nếu trang nội dung iframe sử dụng tên miền phụ của trang chứa iframe, cookie sẽ không còn bị chặn.

— mắt ngạc nhiên
nguồn
Đây là thông tin hữu ích - chỉ là những gì tôi đang tìm kiếm. Mặc dù tôi chắc chắn rằng hầu hết mọi người không thể thay đổi tên miền xung quanh, đó là những gì tôi sẽ làm. Có trang web tôi đang nhúng để tạo một tên miền phụ <mycompany>. <Itscompany> .com ánh xạ tới IP của tôi và Vhost về phía tôi cho tên miền đó và sử dụng URL đó trong iFrame. Phức tạp, nhưng nên chống đạn.
— Bỏ trốn Safari
1
Điều này có thể trở nên phức tạp nếu bạn đang sử dụng https với tên miền phụ, vì máy chủ tên miền phụ sẽ cần chứng chỉ SSL để khớp.
— Roger Halliburton
1

Google thực sự đã để con mèo ra khỏi cái túi này. Họ đã sử dụng nó trong một thời gian để truy cập cookie theo dõi. Nó đã được sửa gần như ngay lập tức bởi Apple = \

bài gốc của tạp chí Phố Wall

— Colin Godsey
nguồn
Tôi biết về điều Google, nhưng tôi chưa thấy gì về Apple thực sự khắc phục lỗi này (và phá vỡ một nửa internet). Bạn có bất kỳ chi tiết về điều đó?
— mscha
1

Đây là một số mã mà tôi sử dụng. Tôi thấy rằng nếu tôi đặt bất kỳ cookie nào từ trang web của mình thì cookie sẽ hoạt động một cách kỳ diệu trong iframe từ đó trở đi.

http://developsocialapps.com/foundations-of-a-facebook-app-framework/

 if (isset($_GET['setdefaultcookie'])) {
        // top level page, set default cookie then redirect back to canvas page
        setcookie ('default',"1",0,"/");
        $url = substr($_SERVER['REQUEST_URI'],strrpos($_SERVER['REQUEST_URI'],"/")+1);
        $url = str_replace("setdefaultcookie","defaultcookieset",$url);
        $url = $facebookapp->getCanvasUrl($url);
        echo "<html>\n<body>\n<script>\ntop.location.href='".$url."';\n</script></body></html>";
        exit();
    } else if ((!isset($_COOKIE['default'])) && (!isset($_GET['defaultcookieset']))) {
        // no default cookie, so we need to redirect to top level and set
        $url = $_SERVER['REQUEST_URI'];
        if (strpos($url,"?") === false) $url .= "?";
        else $url .= "&";
        $url .= "setdefaultcookie=1";
        echo "<html>\n<body>\n<script>\ntop.location.href='".$url."';\n</script></body></html>";
        exit();
    }
— Tom Kincaid
nguồn
1

Một phiên bản hơi đơn giản trong PHP về những gì người khác đã đăng:

if (!isset($_COOKIE, $_COOKIE['PHPSESSID'])) {
    print '<script>top.window.location="https://example.com/?start_session=true";</script>';
    exit();
}

if (isset($_GET['start_session'])) {
    header("Location: https://apps.facebook.com/YOUR_APP_ID/");
    exit();
}
— Charlie Schliesser
nguồn
1

Tôi đã tìm thấy câu trả lời hoàn hảo cho vấn đề này, tất cả là nhờ một anh chàng tên Allan xứng đáng với tất cả tín dụng ở đây. ( http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/ )

Giải pháp của ông rất đơn giản và dễ hiểu.

Trên máy chủ nội dung iframe (tên miền 2), hãy thêm một tệp có tên là startedession.php ở cấp tên miền gốc có chứa:

<?php
// startsession.php
session_start();
$_SESSION['ensure_session'] = true;
die(header('location: '.$_GET['return']));

Bây giờ trên trang web cấp cao nhất chứa iframe (domain1), lệnh gọi đến trang chứa iframe sẽ giống như:

<a href="https://domain2/startsession.php?return=http://domain1/pageWithiFrame.html">page with iFrame</a>

Và đó là nó! Đơn giản :)

Lý do điều này hoạt động là vì bạn đang hướng trình duyệt tới URL của bên thứ ba và do đó bảo nó tin tưởng nó trước khi hiển thị nội dung từ nó trong iframe.

— người dùng1351772
nguồn
0

Tôi đã sử dụng sửa đổi (đã thêm param numquest param vào liên kết) Thủ thuật của Whiteagle và nó hoạt động tốt với safari, nhưng IE liên tục làm mới trang trong trường hợp đó. Vì vậy, giải pháp của tôi cho safari và internet explorer là:

$fbapplink = 'https://apps.facebook.com/[appnamespace]/';
$isms = stripos($_SERVER['HTTP_USER_AGENT'], 'msie') !== false;

// safari fix
if(! $isms  && !isset($_SESSION['signed_request'])) {

    if (isset($_GET["start_session"])) {
        $_SESSION['signed_request'] = $_GET['signed_request'];
        die(header("Location:" . $fbapplink ));

    }
    if (!isset($_GET["sid"])) {
        die(header("Location:?sid=" . session_id() . '&signed_request='.$_REQUEST['signed_request']));
    }
    $sid = session_id();
    if (empty($sid) || $_GET["sid"] != $sid) {
    ?>
    <script>
        top.window.location="?start_session=true";
    </script>
    <?php
    exit;
    }
}

// IE fix
header('P3P: CP="CAO PSA OUR"');
header('P3P: CP="HONK"');


.. later in the code

$sr = $_REQUEST['signed_request'];
if($sr) {
        $_SESSION['signed_request'] = $sr;
} else {
        $sr = $_SESSION['signed_request'];
}
— cotko
nguồn
0

Tôi cũng đang gặp phải vấn đề này, nhưng cuối cùng cũng có giải pháp, Ban đầu trực tiếp tải url iframe trong trình duyệt như cửa sổ bật lên nhỏ sau đó chỉ truy cập các giá trị phiên bên trong iframe.

— Karthik Keyan
nguồn
-2

Tôi quyết định loại bỏ $_SESSIONtất cả các biến cùng nhau và viết một trình bao bọc xung quanh memcache để bắt chước phiên.

Kiểm tra https://github.com/manpreetssethi/utils/blob/master/Session_manager.php

Ca sử dụng: Khoảnh khắc người dùng truy cập vào ứng dụng, lưu trữ yêu cầu đã ký bằng Session_manager và vì nó nằm trong bộ đệm, nên bạn có thể truy cập nó trên bất kỳ trang nào kể từ đó.

Lưu ý: Điều này sẽ không hoạt động khi duyệt riêng tư trong Safari vì session_id đặt lại mỗi khi trang tải lại. (Safari ngu ngốc)

— Manpreet Sethi
nguồn
-9

Bạn có thể giải quyết vấn đề này bằng cách thêm tiêu đề dưới dạng chính sách p3p..tôi cũng gặp vấn đề tương tự trên safari vì vậy sau khi thêm tiêu đề trên đầu tệp đã giải quyết vấn đề của tôi.

<?php
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
?>
— Điên
nguồn
Bạn có chắc chắn điều này (vẫn) hoạt động với phiên bản Safari mới nhất? Chúng tôi đã có các tiêu đề P3P trong nhiều năm, cho IE, nhưng Safari vẫn bị hỏng.
— mscha
2
Hãy thử xóa tất cả các cookie của bạn và kiểm tra lại. Vấn đề không hiển thị nếu trình duyệt của bạn đã có cookie cho trang web có khung của bạn.
— rmarscher
Hmmm, tôi cũng không thể làm cho các tiêu đề P3P hoạt động. Họ vẫn làm việc trong IE!
— Seth Brown
2
Điều này được sử dụng để làm việc. Nhưng đối với phiên bản Safari mới nhất thì không. Xóa bộ nhớ cache của bạn và thử lại ....
— chantheman
2
Tôi muốn nói rằng giải pháp này hoạt động. đảm bảo bạn XÓA TẤT CẢ các cookie trên safari. Và sau đó thử điều này.
— dnuske
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.