django-debug-toolbar görünmüyor

132

Diğer sorulara baktım ve çözemedim ...

Django-debug-toolbar'ı kurmak için aşağıdakileri yaptım:

  1. pip install django-debug-toolbar
  2. ara yazılım sınıflarına eklendi:
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # Uncomment the next line for simple clickjacking protection:
    # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'debug_toolbar.middleware.DebugToolbarMiddleware',
)

3 INTERNAL_IPS Eklendi:

INTERNAL_IPS = ('174.121.34.187',)

4 Yüklü uygulamalara debug_toolbar eklendi

Herhangi bir hata veya herhangi bir şey almıyorum ve araç çubuğu hiçbir sayfada görünmüyor, yönetici bile.

Hatta debug_toolbar şablonlarının dizinini ekledim TEMPLATE_DIRS

python  django  django-debug-toolbar 
— AlexBrand
kaynak
9
Vagrant kullanıyorsanız INTERNAL_IPS, doğru olduğundan emin olun . Kontrol etmenin bir yolu bir görünümde, kendi başlığınızı yazdırmak ve request.META['REMOTE_ADDR']ardından bunu INTERNAL_IPS.
— Will
1
Bu birine yardımcı olabilir. '*'Dahili IP'leri ekleyerek deniyordum ama bu işe yaramıyor. Belirli IP'leri girmelisiniz.
— Luv33preet
Benim settings.py'de, artık MIDDLEWARE, MIDDLEWARE_CLASSES değil
— bertie

Yanıtlar:

175

Aptalca bir soru, ama bundan bahsetmedin, bu yüzden ... Neye DEBUGayarlanmış? YüklenmeyecekseTrue .

Hala çalışmıyorsa, '127.0.0.1'i de eklemeyi deneyin INTERNAL_IPS.

GÜNCELLEME

Bu olmamalı, bir son dakika çaba harekettir var bunu yapmak için, ancak açıkça sadece bazı yapılandırma sorunun olup olmadığını göstermek veya bazı büyük sorunu olup olmadığını olacaktır.

Settings.py'ye aşağıdakileri ekleyin:

def show_toolbar(request):
    return True
SHOW_TOOLBAR_CALLBACK = show_toolbar

Bu, kendini yüklemesi gerekip gerekmediğini belirlemek için hata ayıklama araç çubuğuyla tüm kontrolleri etkili bir şekilde kaldıracaktır; her zaman sadece yüklenecektir. Bunu sadece test amacıyla bırakın, unutursanız ve onunla başlatırsanız, tüm ziyaretçileriniz de hata ayıklama araç çubuğunuzu görebilir.

Açık yapılandırma için, ayrıca resmi belgeler yükleme bölümüne bakın burada .

DÜZENLEME (2015/06/17):

Görünüşe göre nükleer seçeneğin sözdizimi değişmiş. Şimdi kendi sözlüğünde:

def show_toolbar(request):
    return True
DEBUG_TOOLBAR_CONFIG = {
    "SHOW_TOOLBAR_CALLBACK" : show_toolbar,
}

Onların testler bu sözlüğü kullanın.

— Chris Pratt
kaynak
3
Evet, burada daha büyük bir sorun var. Başka bir şey kullanıyorsanız, runserveryeniden başlattığınızdan emin olun. Heck, yeniden başlat runserver. Settings.py'de yaptığınız değişikliklerin gerçekten kaydedildiğinden / tamamlandığından emin olun . * .Pyc dosyalarını kaldırmayı deneyebilirsiniz. * Nix'te, bunu find . -name "*.pyc" -exec rm {} \;proje kökünden kolayca yapabilirsiniz . Son olarak, çalıştırın python manage.py shellve çalıştırın from django.conf import settingsve değerini kontrol edin settings.INSTALLED_APPs.
— Chris Pratt
3
Son soruyla ne demek istediğinizden emin değilim, ancak söz ediyorsanız INTERNAL_IPS, bunlar istemci içindir (Django). Başka bir deyişle, koymak senin böylece IP adresine Eğer ayıklama araç çubuğu görebilirsiniz IP sitesinde çalışıyor olabilir ne olursa olsun.
— Chris Pratt
10
INTERNAL_IPS beni de yakaladı .. Bilgi için teşekkürler
— Lee
12
hattaSHOW_TOOLBAR_CALLBACK = lambda x: True
— John Mee
6
@schillingt evet, bunu kontrol etmeliydim özür dilerim. Sanırım collectstaticher şeyin görünmesi için koşmam gerekiyordu.
— Rob Grant
81

Hata ayıklama araç çubuğu, istekteki ip adresini istiyor .META ['REMOTE_ADDR'] INTERNAL_IPS ayarında ayarlanacak. Görüşlerinizden birine aşağıdaki gibi bir baskı ifadesi ekleyin:

print("IP Address for debug-toolbar: " + request.META['REMOTE_ADDR'])

Ve sonra o sayfayı yükleyin. Settings.py içindeki IP'nin INTERNAL_IPS ayarınızda olduğundan emin olun.

Normalde bilgisayarınızın ip adresine bakarak adresi kolayca belirleyebileceğinizi düşünürdüm, ama benim durumumda sunucuyu bağlantı noktası yönlendirmeli bir Sanal Kutuda çalıştırıyorum ... ve ne olduğunu kim bilebilir. VB'de veya kendi işletim sistemimde ifconfig'de hiçbir yerde görmememe rağmen, REMOTE_ADDR anahtarında görünen IP, araç çubuğunu etkinleştirmenin püf noktasıydı.

— timothyashaw
kaynak
2
Sayfama nginx proxy geçişi aracılığıyla ulaşıyordum, bu nedenle remote_addr benim proxy'imdi ve gerçek ip'im değildi. Proxy ip adresimi eklemem gerekiyordu INTERNAL_IPSve çalışmaya başladı.
— Kurt
1
VirtualBox'taki konuk makinemden, birisine yardımcı olabilirse, ana makinem 10.0.0.2 olarak görülüyor. :)
— mrmuggles
VAGRANT gibi bir sanallaştırma kullanıyorsanız IP'yi kontrol etmek çok yararlıdır
— andilabs
3
Docker'da REMOTE_ADDR benim varsaydığım gibi değildi.
— Aaron McMillin
28

Mevcut kararlı sürüm 0.11.0, araç çubuğunun gösterilmesi için aşağıdaki şeylerin doğru olmasını gerektirir:

Ayarlar dosyası:

  1. DEBUG = True
  2. INTERNAL_IPSsunucu adresinin tersine tarayıcınızın IP adresini dahil etmek için. Yerel olarak göz atıyorsanız bu olmalıdır INTERNAL_IPS = ('127.0.0.1',). Uzaktan göz atıyorsanız sadece genel adresinizi belirtin .
  3. Yüklenecek debug_toolbar uygulaması ie INSTALLED_APPS = (..., 'debug_toolbar',)
  4. Eklenecek hata ayıklama araç çubuğu ara yazılım sınıfı MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). Listede olabildiğince erken yerleştirilmelidir.

Şablon dosyaları:

  1. Tipte olmalı text/html
  2. Kapanış </html>etiketi olmalı

Statik dosyalar:

Statik içerik sunuyorsanız css, js ve html'yi şu şekilde topladığınızdan emin olun: 

./manage.py collectstatic

Django-debug-toolbar'ın gelecek sürümleri hakkında not

Daha yeni, geliştirme sürümleri, 2, 3 ve 4 ayar noktaları için varsayılanları ekledi, bu da hayatı biraz daha basit hale getiriyor, ancak herhangi bir geliştirme sürümünde olduğu gibi hatalar var. Git'in en son sürümünün birImproperlyConfiguredGit'in nginx / uwsgi üzerinden çalışırken hatayla buldum.

Her iki durumda da, en son sürümü github çalıştırmasından yüklemek istiyorsanız:

pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git#egg=django-debug-toolbar

Şunları yaparak da belirli bir işlemi klonlayabilirsiniz: 

pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git@ba5af8f6fe7836eef0a0c85dd1e6d7418bc87f75#egg=django_debug_toolbar
— donturner
kaynak
2
aslında gerekli olan <body> </body> etiketi değil </html>
— Zgr3doo
20

Ayarlamadan DEBUG = Trueayarlara INTERNAL_IPS, istemcimin IP adresine ve hatta Django Hata Ayıklama Araç Çubuğunu manuel olarak yapılandırmaya kadar her şeyi denedim (son sürümlerin ara yazılım ve URL'ler eklemek gibi tüm yapılandırmaları otomatik olarak yaptığını unutmayın). Uzak geliştirme sunucusunda hiçbir şey çalışmadı (yerel olarak çalışmasına rağmen). YALNIZCA işe yarayan şey, araç çubuğunu aşağıdaki gibi yapılandırmaktı:

DEBUG_TOOLBAR_CONFIG = {
    "SHOW_TOOLBAR_CALLBACK" : lambda request: True,
}

Bu, araç çubuğunun gösterilip gösterilmeyeceğine karar veren ve her zaman doğru döndüren varsayılan yöntemin yerini alır.

— Anoyz
kaynak
16

Liman işçisi

Docker içeren bir Docker konteynerinde Django sunucusu ile geliştirme yapıyorsanız , araç çubuğunu etkinleştirme talimatları çalışmaz. Bunun nedeni, eklemeniz gereken gerçek adresin INTERNAL_IPS172.24.0.1 gibi dinamik bir şey olacağı gerçeğiyle ilgilidir. Dinamik olarak değerini ayarlamaya çalışmak yerine INTERNAL_IPS, basit çözüm araç çubuğunu etkinleştiren işlevi değiştirmektir, settings.pyörneğin:

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': lambda _request: DEBUG
}


Bu aynı zamanda serseri gibi diğer dinamik yönlendirme durumları için de çalışmalıdır.

İşte meraklılar için biraz daha ayrıntı. Django_debug_tool'daki araç çubuğunun gösterilip gösterilmeyeceğini belirleyen kod şu şekilde değerini inceler REMOTE_ADDR:

if request.META.get('REMOTE_ADDR', None) not in INTERNAL_IPS:
       return False

bu nedenle REMOTE_ADDR, dinamik docker yönlendirmeniz nedeniyle değerini gerçekten bilmiyorsanız , araç çubuğu çalışmayacaktır. Örneğin dinamik IP değerlerini görmek için docker network komutunu kullanabilirsiniz.docker network inspect my_docker_network_name

— Mark Chackerian
kaynak
15

Araç çubuğum mükemmel çalışıyor. Bu konfigürasyonlarla:

  1. DEBUG = True
  2. INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
  3. DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
  4. Ara katman, şunların ilk öğesidir MIDDLEWARE_CLASSES:
MIDDLEWARE_CLASSES = (
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
)

Umut ediyorum bu yardım eder

— César
kaynak
2
Muhtemelen cevabınızdan IP adresinizi çıkarmalısınız. Bugünlerde çoğu insan geniş bant kullandığından ve çoğu geniş bant bağlantısı IP adresini nadiren değiştirir. Muhtemelen internette dolaşmasını istemezsiniz.
— Chris Pratt
192.168. *. *, Bilgisayara yönlendirici tarafından atanan dahili bir yerel IP adresidir. Harici IP adresi farklıdır.
— Robeezy
@rpod işte tam da bu yüzden birisi onu buna göre düzenledi.
— Yuji 'Tomita' Tomita
Bunun yerine içinde middleware_classes eklemeden arasında, One True Yapılandırma Dosyası kullanarak ve sadece dev ayıklama araç çubuğunu istediğiniz ediyorsanız base.pysize bu eklemek isteyebilirsiniz local.py: MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',) + MIDDLEWARE_CLASSES.
— Rob Grant
12

10.0.2.2Windows'ta INTERNAL_IPS'inize ekleyin , dahili olarak serseri ile kullanılır

INTERNAL_IPS = ('10 .0.2.2 ',)

Bu çalışmalı.

— Baş Koopmans
kaynak
1
Bunun OSX'te Vagrant kullanarak sorunumu çözdüğünü doğruladım.
— Josh
Bu en doğru ve en olası çözüm ve en basit olanı :) Windows 7'de serseri kullanarak çalışma doğrulandı
— doğrulandı
6

Aynı sorunu yaşadım ve sonunda biraz googling yaptıktan sonra çözdüm.

INTERNAL_IPS'de, istemcinin IP adresine sahip olmanız gerekir .

— Farhan Hafeez
kaynak
4

Araç çubuğunun gizli kalmasına neden olabilecek başka bir şey de gerekli statik dosyaları bulamamasıdır. Debug_toolbar şablonları {{STATIC_URL}} şablon etiketini kullanır, bu nedenle statik dosyalarınızda hata ayıklama araç çubuğu adında bir klasör olduğundan emin olun.

Collectstatic yönetim komutu çoğu kurulumda bununla ilgilenmelidir.

— AgDude
kaynak
3

Önceki cevaplara bir ek:

araç çubuğu görünmüyorsa, ancak html'de yükleniyorsa (bir tarayıcıda sitenizin html'sini kontrol edin, aşağı kaydırın)

sorun, hata ayıklama araç çubuğu statik dosyalarının bulunamaması olabilir (bunu sitenizin erişim günlüklerinde de görebilirsiniz, örneğin, /static/debug_toolbar/js/toolbar.js için 404 hataları)

Daha sonra aşağıdaki şekilde düzeltilebilir (nginx ve apache örnekleri):

nginx yapılandırması:

location ~* ^/static/debug_toolbar/.+.(ico|css|js)$ {
    root [path to your python site-packages here]/site-packages/debug_toolbar;
}

apache yapılandırması:

Alias /static/debug_toolbar [path to your python site-packages here]/site-packages/debug_toolbar/static/debug_toolbar

Veya:

manage.py collectstatic

Collectstatic hakkında daha fazla bilgi için: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic

Veya debug_toolbar statik dosyalarının debug_toolbar klasörünü ayarladığınız statik dosyalar klasörünüze manuel olarak taşıyın

— şilin
kaynak
3

Yapılandırmayı pydanny'nin cookiecutter-django'sundan denedim ve benim için çalıştı:

# django-debug-toolbar
MIDDLEWARE_CLASSES = Common.MIDDLEWARE_CLASSES + ('debug_toolbar.middleware.DebugToolbarMiddleware',)
INSTALLED_APPS += ('debug_toolbar',)

INTERNAL_IPS = ('127.0.0.1',)

DEBUG_TOOLBAR_CONFIG = {
    'DISABLE_PANELS': [
        'debug_toolbar.panels.redirects.RedirectsPanel',
    ],
    'SHOW_TEMPLATE_CONTEXT': True,
}
# end django-debug-toolbar

Resmi django-debug-toolbar belgelerinde belirtildiği gibi 'debug_toolbar.apps.DebugToolbarConfig'yerine Django 1.7'yi kullandığım'debug_toolbar' için ekleyerek değiştirdim .

— metakermit
kaynak
2

Benim durumumda, henüz burada bahsedilmeyen başka bir sorundu: Ara yazılımlar listemde GZipMiddleware vardı.

Hata ayıklama araç çubuğunun otomatik yapılandırması, hata ayıklama araç çubuğunun ara yazılımını en üste koyduğundan, yalnızca, araç çubuğunu ekleyemediği gzipli HTML'yi "gör" alır.

Geliştirme ayarlarımda GZipMiddleware'i kaldırdım. Hata ayıklama araç çubuğunun yapılandırmasını manuel olarak ayarlamak ve ara yazılımı GZip'lerden sonra yerleştirmek de çalışmalıdır.

— RemcoGerlich
kaynak
GZip'i görünüm düzeyinde ile etkinleştirmek bile gzip_pagearaç çubuğunun kaybolmasına neden olur. docs.djangoproject.com/en/2.0/topics/http/decorators/…
— Brachamul
2

Benim durumumda sadece python derlenmiş dosyaları kaldırmam gerekiyor ( *.pyc)

— dnaranjo
kaynak
Bu yorum için teşekkürler, bu sabah beni zihinsel bir krizden kurtardı. Diğer her şey doğru görünüyorsa - ve bu proje daha önce benim için iyi çalışıyorsa - bunu deneyin ve çözüp çözmediğine bakın. DDT HTML / JS sayfadaydı, her şey yolunda görünüyordu, ancak yine de görünmüyordu. Pyc dosyalarını temizledim ve tekrar görünmeye başladı
— Shane
2

django 1.8.5:

Hata ayıklama araç çubuğu görüntüsünü almak için proje url.py dosyasına aşağıdakileri eklemem gerekiyordu. Bundan sonra hata ayıklama araç çubuğu görüntülenir.

 from django.conf.urls import include
 from django.conf.urls import patterns
 from django.conf import settings


  if settings.DEBUG:
      import debug_toolbar
      urlpatterns += patterns('',
              url(r'^__debug__/', include(debug_toolbar.urls)),
              )

django 1.10: ve üstü:

from django.conf.urls import include, url
from django.conf.urls import patterns
from django.conf import settings


if settings.DEBUG:

  import debug_toolbar
  urlpatterns =[
         url(r'^__debug__/', include(debug_toolbar.urls)),
         ] + urlpatterns

Ayrıca, ara yazılımınıza debug_toolbar'ı eklemeyi unutmayın. Hata Ayıklama Araç Çubuğu çoğunlukla bir ara yazılımda uygulanır. Ayarlar modülünüzde aşağıdaki gibi etkinleştirin: (django daha yeni sürümler)

MIDDLEWARE = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
#

Eski tarz ara yazılım: (Ara Yazılımda _CLASSES anahtar çalışmasına sahip olmanız gerekir)

MIDDLEWARE_CLASSES = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
# ...
]
— Stryker
kaynak
1

Bu belirli yazar için durum böyle değildi, ancak Hata Ayıklama Araç Çubuğu'nun gösterilmemesi ile mücadele ediyordum ve işaret ettikleri her şeyi yaptıktan sonra, MIDDLEWARE siparişiyle ilgili bir sorun olduğunu öğrendim. Bu yüzden ara yazılımı listenin başına koymak işe yarayabilir. Önce benimki:

MIDDLEWARE_CLASSES = ( 'debug_toolbar.middleware.DebugToolbarMiddleware', 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'dynpages.middleware.DynpageFallbackMiddleware', 'utils.middleware.UserThread', )

— Anderson Santos
kaynak
0

şablonlarınızda bir kapanış etiketi olduğundan emin olmalısınız.

Benim sorunum, şablonlarımda normal html etiketleri olmaması, içeriği sadece düz metin olarak görüntülüyorum. Her html dosyasını bir etiketi olan base.html'den miras alarak çözdüm.

— user1552891
kaynak
0

Benim için bu, görünüşe göre INTERNAL_IPS ile eşleşmeyen 127.0.0.1:8000adres çubuğuna yazmak kadar basitti localhost:8000.

— TimStaley
kaynak
0

Ben de aynı sorunu yaşadım, Apache'nin hata günlüğüne bakarak çözdüm. Apache'yi mac os x'de mod_wsgi ile çalıştırdım debug_toolbar'ın tamplete klasörü yüklenmiyor

Günlük örneği:

==> /private/var/log/apache2/dummy-host2.example.com-error_log <==
[Sun Apr 27 23:23:48 2014] [error] [client 127.0.0.1] File does not exist: /Library/WebServer/Documents/rblreport/rbl/static/debug_toolbar, referer: http://127.0.0.1/

==> /private/var/log/apache2/dummy-host2.example.com-access_log <==
127.0.0.1 - - [27/Apr/2014:23:23:48 -0300] "GET /static/debug_toolbar/css/toolbar.css HTTP/1.1" 404 234 "http://127.0.0.1/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0"

Bu satırı VirtualHost dosyama ekledim:

Alias /static/debug_toolbar /Library/Python/2.7/site-packages/debug_toolbar/static/debug_toolbar
  • Tabii ki python yolunu değiştirmelisin
— Andre Manzano
kaynak
0

Vagrant kullanırken de aynı sorunu yaşadım. Bu sorunu ::ffff:192.168.33.1INTERNAL_IPS'e aşağıdaki örnek gibi ekleyerek çözdüm.

INTERNAL_IPS = (
    '::ffff:192.168.33.1',
)

Bunun 192.168.33.10Vagrantfile'daki özel ağımdaki IP olduğunu hatırlamak.

— Adriano Silva
kaynak
0

Bu sorunu yaşadım ve hata ayıklama araç çubuğunu kaynaktan yüklemem gerekiyordu.

Sürüm 1.4, PureCSS ve görünüşe göre diğer CSS çerçevelerini kullanırsanız, gizli olduğu bir soruna sahiptir.

Bunu düzelten commit budur.

Dokümanlar, kaynaktan nasıl kurulacağını açıklar.

— Petko M
kaynak
0

Pycharm 5 kullanan herkes için - şablon hata ayıklama bazı sürümlerde orada çalışmıyor. 5.0.4'te düzeltildi, etkilenen sürümler - 5.0.1, 5.0.2 Check out sorunu

Bunu bulmak için ÇOK zaman harcayın. Belki birine yardım eder

— wolendranh
kaynak
0

Üzerinde çalıştığım kodda, ana isteğin işlenmesi sırasında çok sayıda küçük istek yapıldı (bu çok özel bir kullanım durumu). Aynı Django'nun iş parçacığı tarafından ele alınan isteklerdi. Django hata ayıklama araç çubuğu (DjDT) bu davranışı beklemez ve DjDT'nin araç çubuklarını ilk yanıta dahil eder ve ardından iş parçacığı için durumunu kaldırır. Dolayısıyla, ana istek tarayıcıya geri gönderildiğinde yanıta DjDT dahil edilmedi.

Alınan dersler: DjDT, iş parçacığı başına durumunu kaydeder. İlk yanıttan sonra bir iş parçacığı için durumu kaldırır.

— jozo
kaynak
0

Bana sahip olan şey modası geçmiş bir tarayıcı!

Hata ayıklama araç çubuğundan bazı stil sayfalarını yüklediğini fark etti ve bunun bir ön uç sorunu olabileceğini tahmin etti.

— ogurets
kaynak
0

Bu sorunun biraz eski olduğunu biliyorum ama bugün django-toolbar'ı docker ile kurdum ve aynı sorunla karşılaştım, bu benim için çözdü

INTERNAL_IPS = ["127.0.0.1", "10.0.2.2"]

import socket
hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
INTERNAL_IPS += [".".join(ip.split(".")[:-1] + ["1"]) for ip in ips]

Bir yorumda okuduğum gibi, sorun şu ki, docker dinamik bir ip kullanıyor, bunu çözmek için yukarıdaki koddan ip'i alabiliriz

— Esequiel Albornoz
kaynak
-1

Apache wsgi kullanıyorsanız, kodunuzu yeniden derlemeye zorlamak için .wsgi dosyasına dokunmayı unutmayın. aptal hatayı gidermek için 20 dakikamı harcayın :(

— igameland
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.