2012-02-14 16 views
57

Jestem w trakcie opracowywania aplikacji dla klienta, który będzie miał certyfikat SSL i będzie obsługiwany pod https. Jednakże, aby zintegrować się z istniejącą witryną, chcą zapewnić nawigację wewnątrz elementu iframe.Niepewna zawartość w iframe na bezpiecznej stronie

Widzę, że powoduje to problemy, ponieważ spodziewałbym się, że przeglądarka będzie narzekać na mieszankę bezpiecznych i niezabezpieczonych treści na stronie. Spojrzałem na podobne pytania tutaj i wszystkie wydają się odnosić do tego w drugą stronę (bezpieczna zawartość w iframe).

Co chciałbym wiedzieć, to: czy spowoduje to problemy z umieszczeniem niezabezpieczonej zawartości w elemencie iframe, umieszczonym na bezpiecznej stronie, a jeśli tak, jakie będą tego problemy?

Idealnie, jeśli nie jest to dobry pomysł (i mam silne poczucie, że tak nie jest), muszę być w stanie wyjaśnić to klientowi.

+0

Czy używasz głównej strony w prostym protokole HTTP i osadzasz element iframe korzystający z HTTPS? – Bruno

+4

Nie, odwrotnie - strona główna to HTTPS, iframe to zwykły HTTP. Zmieniłem to pytanie, aby było to jaśniejsze. – moogal

+1

Istnieje już [liczba pytań] (http://stackoverflow.com/search?q=https+iframe) o tym już. W pewnym sensie jest to zły pomysł, ponieważ użytkownicy nie będą wiedzieć, która część strony jest bezpieczna, a która nie. – Bruno

Odpowiedz

22

Jeśli strona jest dostępna poprzez https://www.example.com/main/index.jsp (SSL), a następnie przeglądarka będzie narzekać na „Ta strona zawiera zarówno bezpieczne i niebezpieczne przedmioty” czy są jakieś środki w kodzie HTML, które są przywoływane z http:// (bez SSL) . Obejmuje to elementy iframe.

Jeśli strona nawigacji znajduje się na tym samym serwerze, a następnie można zapobiec komunikat „niebezpieczne treści” przy użyciu względny adres URL takiego ...

<iframe src="/app/navigation.jsp" /> 

Od swoje pytanie brzmi jak swojej strony nawigacyjnej jest podawane z osobnego hosta i jesteś zmuszony użyć czegoś jak ten

<iframe src="http://otherserver.example.com/app/navigation.jsp" /> 

które będą oczywiście powodować komunikat „niebezpieczne treści” w swojej przeglądarce.

Twoje tylko rozwiązania są albo

  1. wdrożenia protokołu SSL na serwerze trzymając swoją stronę nawigacji, dzięki czemu można używać https:// celach informacyjnych iframe lub

  2. przenieść aplikację nawigacji na tym samym serwerze więc możesz użyć względnego adresu URL.

Osobiście nie widzę dlaczego nawigacja będzie na innego hosta, bo wtedy masz zamiar dostać problemy skryptów między domenami JavaScript (chyba jakiś ostry JSONP jest zaangażowany).

+15

Integracja z strona trzecia, w której nie można uruchomić swojego kodu, jest dobrym przykładem tego, kiedy potrzebna jest lepsza opcja. – freyley

+2

Czy podejście 'src ="/app/navigation.jsp "' nie wymaga, aby zawartość elementu iframe była dostępna pod HTTPS? Jednak zgodnie z OP, iframe jest w zwykłym HTTP. – KajMagnus

+0

Kolejnym przykładem jest sytuacja, w której użytkownicy mają zezwolić na umieszczanie dowolnych adresów URL. Na przykład na stronie projektu strony internetowej. – Thayne

35

Jeśli twoja strona jest http, to pozwala iframe z treści https.

Ale jeśli twoja strona jest https, to nie pozwala na zawartość http.

Pozwala odrzucić następujące możliwości.

page - iframe - status 

http - http - allowed 
http - https - allowed 
https- http - not allowed 
https- https - allowed 
+3

https - https - dozwolone - potwierdzone na [sc2vault.com] (http://www.sc2vault.com/) – bradleygsmith

+3

https - https - niezabezpieczone skrypty - niedozwolone – coderek

+3

https - https - niepoprawne obrazy - dozwolone – coderek

-1

Spróbuj usunąć http: znaków w wartości atrybutu src jako tak:

<iframe src="//example.com/thefile.htm"></iframe> 

Jest to oczywiście obejście, bezpieczeństwo jest ważne, więc nie ominąć beztrosko, ale w każdym razie to tylko raz mi podobny problem.

+14

to nie rozwiąże problemu. po prostu mówi przeglądarce "śmiało i używaj dowolnego protokołu, którego używałeś, aby uzyskać dostęp do tej strony". w tym przypadku jest to odpowiednik "https: //example.com ...", który nie rozwiązuje problemu z witryną example.com dostępną tylko za pośrednictwem http –

+1

Za pomocą tej techniki rozwiązałem mój problem za każdym razem w każdej przeglądarce, gdy tego rodzaju Obejście problemu jest tymczasowe – bastien

+0

Jak zauważył @RobertLevy, nie rozwiązuje to problemu. Jest to w rzeczywistości dobra praktyka i najlepszy sposób korzystania z dowolnego protokołu używanego przez rodzica. To oczywiście działa tylko wtedy, gdy odpowiedni zasób obsługuje również "https" i "http" – nuts

Powiązane problemy