├── lab_03
├── filters.png
└── readme.md
├── lab_05
├── screen_1.png
└── readme.md
├── lab_08
├── graphql_1.png
├── graphql_2.png
├── graphql_3.png
├── graphql_4.png
└── readme.md
├── lab_06
├── postman_auth.png
└── readme.md
├── readme.md
├── lab_01
└── readme.md
├── lab_02
└── readme.md
├── lab_04
└── readme.md
├── lab_09
└── readme.md
└── lab_07
└── readme.md
/lab_03/filters.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kropiak/app_www/HEAD/lab_03/filters.png
--------------------------------------------------------------------------------
/lab_05/screen_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kropiak/app_www/HEAD/lab_05/screen_1.png
--------------------------------------------------------------------------------
/lab_08/graphql_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kropiak/app_www/HEAD/lab_08/graphql_1.png
--------------------------------------------------------------------------------
/lab_08/graphql_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kropiak/app_www/HEAD/lab_08/graphql_2.png
--------------------------------------------------------------------------------
/lab_08/graphql_3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kropiak/app_www/HEAD/lab_08/graphql_3.png
--------------------------------------------------------------------------------
/lab_08/graphql_4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kropiak/app_www/HEAD/lab_08/graphql_4.png
--------------------------------------------------------------------------------
/lab_06/postman_auth.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/kropiak/app_www/HEAD/lab_06/postman_auth.png
--------------------------------------------------------------------------------
/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025/2026Z
2 |
3 | ## 1. Cel i zakres przedmiotu
4 |
5 | Celem przedmiotu jest przybliżenie studentowi zagadnień związanych z projektowaniem aplikacji WWW z wykorzystaniem języka Python oraz frameworka Django. W trakcie zajęć główny nacisk zostanie położony na backend (czyli część aplikacji związana z implementacją funkcjonalności po stronie serwera), ale zajmiemy się też budową prostych widoków, czyli frontendem.
6 |
7 | W trakcie zajęć student pozna m.in. zagadnienia takie jak:
8 | * konfiguracja bazy danych na potrzeby aplikacji
9 | * obsługa narzędzia Git
10 | * tworzenie i zarządzanie modelami we frameworku Django
11 | * migracja bazy i rozwiązywanie problemów z migracjami
12 | * implementacja logiki biznesowej (wymagań klienta) w projekcie
13 | * tworzenie API REST-owego na potrzeby różnych technologii frontendowych
14 | * obsługa i implementacja autentykacji i uwierzytelniania z użyciem Django
15 | * poznanie narzędzi zarządzania projektem Django oraz panelu administratora i jego możliwości
16 |
17 |
18 | ## 2. Oprogramowanie
19 |
20 | W trakcie zajęć do pracy niezbędne będzie posiadanie:
21 | * zainstalowanego interpretera **Pythona** w wersji 3.11 lub nowszej
22 | * **framework Django** w wersji 5.2.* - poczytaj release notes: https://docs.djangoproject.com/en/5.2/releases/5.2/
23 | * narzędzie IDE, preferowane **PyCharm Professional** (licencja studencka) lub wersja Community. Może to być również inne oprogramowanie ze wsparciem dla języka Python np. Visual Studio Code.
24 | * narzędzie Git do zarządzania kodem projektu
25 | * możliwe, że w zależności od konfiguracji projektu niezbędne będzie zainstalowanie i konfiguracja odpowiedniego serwera bazy danych
26 |
27 | ## 3. Warunki zaliczenia przedmiotu.
28 |
29 | - Efektem finalnym pracy na zajęciach będzie **projekt API** stworzony w Django Rest Framework lub po uzgodnieniu w innym frameworku,
30 | - Studenci mogą dobrać się w pary :dancers: lub pracować samodzielnie :dancer:,
31 | - Projekt studenta będzie przechowywany w **publicznym repozytorium GitHub**, do którego prowadzący będzie miał wgląd przez cały okres trwania zajęć,
32 | - W przypadku pracy grupowej, obie osoby muszą być dodane jako collaborator do repozytorium,
33 | - Oceniane będą:
34 | - Systematyczność commitów (oraz ich [sens](https://medium.com/@steveamaza/how-to-write-a-proper-git-commit-message-e028865e5791)),
35 | - Jakość kodu programistycznego,
36 | - Implementacja zagadnień przedstawionych na zajęciach,
37 | - Poziom skomplikowania projektu (np. ilość modeli, działanie endpointów, itp.)
38 | - Proponowany temat API (co te API będzie robić) jest dowolny i będzie przedstawiony prowadzącemu na drugich zajęciach.
39 | - Prowadzący rezerwuje możliwość przeprowadzenia kolokwium w przypadku braku pracy na zajęciach przez grupę studentów.
40 |
41 | ## 4. Wymagania projektu.
42 |
43 | Zakres projektu zaliczeniowego:
44 | 1. **Modele**:
45 | * 4-5 adekwatnych do projektu modeli
46 | 2. **Uwierzytelnianie (preferowany token) i autoryzacja.**
47 | * Co najmniej 2 konta z różnym poziomem dostępu do endpointów (np. admin, user)
48 | 3. **Endpointy:**
49 | * Rejestracja użytkownika aplikacji (opcjonalne)
50 | * CRUD
51 | * Minimum 2 endpointy, które wyjdą poza schemat CRUD, np. zestawienie miesięczne zamówień, lista wypożyczeń dla użytkownika, lista towarów zaczynających się od itp.
52 |
53 |
--------------------------------------------------------------------------------
/lab_08/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## Lab 8 - Wprowadzenie do GraphQL.
4 |
5 | GraphQL jest językiem zapytań do API, który w odróżnieniu od REST API pozwala precyzyjnie określić listę cech obiektów, które chcemy zwrócić (po stronie aplikacji klienta) w zależności od potrzeb. Oznacza to, że poprawnie definiując zapytania możemy uniknąć ofektu pobierania zbyt dużej liczby danych (overfetching) lub zbyt małej (underfetching).
6 |
7 |
8 | Poniżej znajduje się instrukcja uruchomienia modułu `graphene` pozwalającego na przetestowanie GraphQL w istniejącym projekcie Django.
9 |
10 | **Krok 1.**
11 |
12 | Instalacja graphene:
13 |
14 | ```bash
15 | pip install graphene-django
16 | ```
17 |
18 | **Krok 2.**
19 | Dodanie definicji do pliku `settings.py`
20 |
21 | ```python
22 | INSTALLED_APPS = [
23 | ...
24 | "graphene_django"
25 | ]
26 | ```
27 |
28 | **Krok 3.**
29 |
30 | Edycja GŁÓWNEGO pliku `urls.py`
31 |
32 | ```python
33 | ...
34 | from django.views.decorators.csrf import csrf_exempt
35 | from graphene_django.views import GraphQLView
36 |
37 | urlpatterns = [
38 | path('admin/', admin.site.urls),
39 | path("graphql", csrf_exempt(GraphQLView.as_view(graphiql=True))),
40 | ]
41 | ```
42 | **Krok 4.**
43 |
44 | Dodanie pliku `projekt/schema.py` (tu dla mojej aplikacji ankiety) z zawartością:
45 |
46 | ```python
47 | import graphene
48 | from graphene_django import DjangoObjectType
49 |
50 | from ankiety.models import Person, Team
51 |
52 |
53 | # dzięki wykorzystaniu klasy DjangoObjectType możemy w łatwy sposób
54 | # wskazać klasę wcześniej zdefiniowanego modelu, która zostanie wykorzystana
55 | # w schemie GraphQL umożliwiając połączenie Django QuerySet oraz zapytań
56 | # poprzez GraphQL. Podobnie jak w przypadku definicji własności w klasach
57 | # administracyjnych danego modelu (plik admin.py) tutaj też możemy określić
58 | # np. listę pól, które poprzez GraphQL chcemy wystawić z danego modelu
59 | class PersonType(DjangoObjectType):
60 | class Meta:
61 | model = Person
62 | fields = ("id", "name", "shirt_size", "miesiac_dodania", "team")
63 | # lub
64 | # fields = "__all__"
65 |
66 | class TeamType(DjangoObjectType):
67 | class Meta:
68 | model = Team
69 | fields = ("id", "name", "country")
70 |
71 | # klasa Query pozwala określić pola (tu np. all_teams, person_by_id, itd.)
72 | # które są dostępne, a następnie Resolvery, który definiują w jaki sposób
73 | # dane dla wskazanego pola będą pobierane (tu już używamy znany nam
74 | # sposób z użyciem Django QuerySet)
75 |
76 | class Query(graphene.ObjectType):
77 | # typ graphene.List określa, że zwracana będzie lista obiektów danego typu
78 | all_teams = graphene.List(TeamType)
79 |
80 | # tu określamy, że zwrócony będzie obiekt typu PersonType, a jego wyszukanie
81 | # odbędzie się na podstawie jego atrybutu id o typie Int, który jest wymagany
82 | person_by_id = graphene.Field(PersonType, id=graphene.Int(required=True))
83 |
84 | all_persons = graphene.List(PersonType)
85 | person_by_name = graphene.Field(PersonType, name=graphene.String(required=True))
86 | find_persons_name_by_phrase = graphene.List(PersonType, substr=graphene.String(required=True))
87 |
88 | # resolver dla pola all_teams
89 | # root główny obiekt wartości przekazywany przez zapytanie
90 | # info informacje z resolvera
91 | # args słownik (opcjonalnie), parametrów przekazywanych do resolvera
92 | def resolve_all_teams(root, info):
93 | return Team.objects.all()
94 |
95 | def resolve_person_by_id(root, info, id):
96 | try:
97 | return Person.objects.get(pk=id)
98 | except Person.DoesNotExist:
99 | raise Exception('Invalid person Id')
100 |
101 | def resolve_person_by_name(root, info, name):
102 | try:
103 | return Person.objects.get(name=name)
104 | except Person.DoesNotExist:
105 | raise Exception(f'No Person with name \'{name}\' found.')
106 |
107 | def resolve_all_persons(root, info):
108 | """ zwraca również wszystkie powiązane obiekty team dla tego obiektu Person"""
109 | return Person.objects.select_related("team").all()
110 |
111 | def resolve_find_persons_name_by_phrase(self, info, substr):
112 | return Person.objects.filter(name__icontains=substr)
113 |
114 |
115 | schema = graphene.Schema(query=Query)
116 | ```
117 |
118 | **Krok 5.**
119 |
120 | Dodanie wpisu do `settings.py`
121 |
122 | ```python
123 | GRAPHENE = {
124 | "SCHEMA": "schema.schema"
125 | }
126 | ```
127 |
128 | **Krok 6.**
129 |
130 | Uruchamiamy serwer i przechodzimy pod adres http://127.0.0.1/graphql i możemy wykonać zapytania w przedstawiony poniżej sposób z efektem widocznym po prawej stronie.
131 |
132 | 
133 | 
134 | 
135 | 
136 |
137 | Oficjalna strona GraphQL: https://graphql.org/
138 | Strona projektu Graphene Python: https://graphene-python.org/
139 |
140 |
141 | **Zadania**
142 |
143 | 0. Pracę wykonaj na nowym branchu.
144 | 1. Odtwórz w swojej aplikacji kolejne kroki przedstawione w labie aby uruchomić możliwość korzystania z GraphQL. Wspomagaj się materiałami z wykładu.
145 | 2. Dodaj jeszcze 3 dodatkowe resolvery pozwalające na odpytanie API za pomocą GraphQL, które pozwolą np. odfiltrować obiekty po fragmencie nazwy, wyświetlić ilość obiektów z daną wartością atrybutu (np. liczba postów dla danego użytkownika).
146 | 3. Dla modelu `Post` stwórz również mutacje pozwalające na tworzenie, edycję i usuwanie encji tego typu.
147 |
148 | Zapytania GraphQL zapisz w pliku `lab_8_zadania.md` w folderze projektu na tym branchu.
149 |
--------------------------------------------------------------------------------
/lab_03/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## Lab 3
4 | ---
5 | ### **1. Modele w Django. Ciąg dalszy**
6 |
7 |
8 | Oprócz typowego mapowania obiektowo-relacyjnego klasy modeli frameworka Django oferują dużo więcej możliwości, m.in. implementację funkcji pomocniczych, określenie domyślnego porządku sortowania zwracanych krotek, określenie parametrów walidacji i inne. Poniżej zostaną zaprezentowane niektóre z możliwości wraz z przykładami użycia.
9 |
10 | Przydatne linki do dokumentacji, które mogą się przydać w trakcie rozwiązywania zadań:
11 | 1. Lista dostępnych pól klas modeli: https://docs.djangoproject.com/pl/5.2/ref/models/fields/#model-field-types
12 | 2. Atrybuty modeli: https://docs.djangoproject.com/pl/5.2/topics/db/models/#field-options
13 | 3. Klasa QuerySet i dostępne metody: https://docs.djangoproject.com/pl/5.2/ref/models/querysets/
14 |
15 | ### Zadania
16 |
17 | **Zadanie 1**
18 | Dodaj do aplikacji `posts` nowy model `Post` zgodnie z poniższą definicją:
19 | * pole `title` typu krótki tekst, max. 150 znaków,
20 | * pole `text` z długim tekstem,
21 | * pole `topic`, klucz obcy do modelu `Topic`, usuwanie kaskadowe,
22 | * pole `slug` typu `SlugField`,
23 | * pole `created_at` typu data i czas, wartość wstawiana automatycznie w momencie dodania rekordu,
24 | * pole `updated_at` typu data i czas, wartość aktualizowana po każdej aktualizacji instancji obiektu,
25 | * pole `created_by`, które jest kluczem obcym do wbudowanej klasy `django.contrib.auth.models.User`.
26 |
27 | **Zadanie 2**
28 | Zarejestruj model w panelu administracyjnym Django. Znajdź w dokumentacji modułu admin ([link](https://docs.djangoproject.com/pl/5.2/ref/contrib/admin/)) zobacz jak deklaruje się pola modelu tylko do odczytu i ustaw taką własność dla pola `created_at` modelu `Post`.
29 |
30 | **Zadanie 3**
31 | Przesłoń metodę `__str__()` zdefiniowanych modeli `Category`, `Topic` oraz `Post` według poniższej instrukcji:
32 | * `Category` - nazwa kategorii,
33 | * `Topic` - nazwa tematu,
34 | * `Posts` - pierwsze 5 wyrazów tekstu posta + '...' jeżeli dłuższy.*
35 |
36 | \* Jeżeli dodamy klasę PostAdmin w `admin.py` oraz okreśłimy listę kolumn do wyświetlenia, należy to obsłużyć jako dodatkowe pole w klasie `PostAdmin` (definiowane przez osadzenie funkcji w tej klasie).
37 |
38 | **Zadanie 4**
39 | Bazując na przykładzie z dokumentacji https://docs.djangoproject.com/pl/5.2/topics/db/models/#meta-options dodaj właściwość `META` sortując domyślnie model `Category` po nazwie alfabetycznie, `Topic` podobnie, a `Post` po dacie dodania od najnowszych.
40 |
41 | **Zadanie 5**
42 |
43 | W panelu administracyjnym dla dodanych modeli nie są widoczne wszystkie pola na liście wszystkich obiektów lecz tylko jedno z nich (domyślnie id lub to co w przesłoniętej funkcji `__str__()`). Aby to zrobić należy najpierw zdefiniować w pliku `admin.py` klasę admin dla danego modelu (ModelAdmin), a następnie zdefiniować listę pól do wyświetlenia w zmiennej `list_display`. Przykład poniżej:
44 |
45 | **_Listing 1_**
46 | ```python
47 | # dla przykładowej klasy
48 | class PersonAdmin(admin.ModelAdmin):
49 | # zmienna list_display przechowuje listę pól, które mają się wyświetlać w widoku listy danego modelu w panelu administracynym
50 | list_display = ['name', 'shirt_size']
51 |
52 | # ten obiekt też trzeba zarejestrować w module admin
53 | admin.site.register(Person, PersonAdmin)
54 | ```
55 |
56 | **Zadanie 6**
57 | Dodaj klasy `ModelAdmin` dla wszystkich zdefiniowanych modeli i zmień listę wyświetlanych kolumn w panelu administracyjnym.
58 |
59 | **Zadanie 7**
60 | Zmodyfikuj kod aplikacji tak, żeby na liście modeli `Post` w panelu administracyjnym wyświetlana została również kolumna `Topic` o postaci 'nazwa topiku (nazwa kategorii)' np. `Batman (Filmy)`. Podpowiedź: sprawdź w dokumentacji modułu admin opis działania adnotacji `@admin.display` ([link](https://docs.djangoproject.com/pl/5.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display)).
61 |
62 | ---
63 | W panelu administracyjnym możliwe jest również dodanie filtrów do widoków. Cały proces polega na dodaniu pola `filter_list` w klasie admin danego modułu:
64 |
65 | **_Listing 2_**
66 | ```python
67 | # przykład i wizualizacja dla modeli Person oraz Team.
68 |
69 | class PersonAdmin(admin.ModelAdmin):
70 | list_filter = ['team']
71 | ```
72 | 
73 |
74 |
75 | W zależności od typu pola zostanie wyświetlony odpowiedni filtr. W przypadku niektórych rodzajów i dużej liczby unikalnych wartości używanie filtrów może być niepraktyczne ze względów wydajnościowych i wizualnych.
76 |
77 | ---
78 |
79 | **Zadanie 8**
80 | Dodaj filtr dla tematów (topic), kategorii oraz użytkowników dla klasy `Post` w panelu administracyjnym. Dodaj filtry nazw dla tematów oraz kategorii. Przetestuj działanie filtrów.
81 |
82 | **Zadanie 9**
83 | Przeczytaj informację o możiwości automatycznego generowania wartości pola w dokumentacji(https://docs.djangoproject.com/pl/5.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.prepopulated_fields) i zastosuj to dla pola `SlugField` modelu `Post`, które będzie generowane z pola `title`.
84 |
85 | **Zadanie 10**
86 | Korzystając z dokumentacji API klasy `QuerySet` z pkt. 3 wykonaj następujące zapytania za pomocą shella Django (**kod Pythona z zapytaniami umieść w pliku lab_3_zadanie_10.md w swoim repozytorium**):
87 | * wyświetl wszystkie obiekty modelu `Category`,
88 | * wyświetl obiekt modelu `Category` z id = 3,
89 | * wyświetl obiekty modelu `Category`, których nazwa rozpoczyna się na wybraną przez Ciebie literę alfabetu (tak, żeby był co najmniej jeden wynik),
90 | * wyświetl unikalną listę nazw kategorii ze wszystkich dodanych tematów (topików),
91 | * wyświetl tytuły postów posortowane alfabetycznie malejąco,
92 | * dodaj nową instancję obiektu klasy `Category` i zapisz w bazie.
93 |
94 | **Zadanie 11**
95 | Jeżeli nie robiłeś/-aś tego wcześniej to zatwierdź wszystkie zmiany w danym branchu i spróbuj wykonać merge z główną gałęzią. Proponuję wykonać tę operację przy pomocy interfejsu IDE PyCharm, aby przetestować wbudowane narzędzie do wspomagania procesu merge (o ile wystąpią konflikty).
--------------------------------------------------------------------------------
/lab_01/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2024Z
2 |
3 | ## Lab 1
4 | ---
5 |
6 |
7 | # 1. Warto zacząć od...
8 |
9 | 1.1 Zanim rozpoczniesz przygotowanie swojego pierwszego projektu z użyciem Django 4.2 rzuć okiem na release notes dla tej wersji: https://docs.djangoproject.com/en/5.2/releases/5.2/
10 |
11 | 1.2 Zachęcam również do zaglądnięcia do kilku ciekawych tutoriali (poza oficjalnym oczywiście) wprowadzających do tworzenia aplikacji z użyciem Django:
12 | * https://realpython.com/get-started-with-django-1/ (i więcej kursów z tej strony w tematyce Django: https://realpython.com/tutorials/django/ )
13 | * https://www.w3schools.com/django/
14 |
15 |
16 |
17 | # Zadania
18 |
19 | 1. Jeżeli korzystasz na zajęciach ze swojego sprzętu to zainstaluj niezbędne oprogramowanie.
20 | 2. Stwórz środowisko wirtualne z interpreterem python na potrzeby swojego projektu.
21 | 3. Zainstaluj niezbędne paczki (aktualnie pakiet o nazwie `django` powinien wystarczyć, wskaż tu wersję 5.2). W razie problemów z instalacją rzuć okiem na oficjalną dokumentację pod adresem https://docs.djangoproject.com/pl/5.2/intro/install/
22 | 4. Przygotuj swój pierwszy projekt oraz aplikację Django (warto znać różnicę między tymi pojęciami) bazując na oficjalnym tutorialu znajdującym się pod adresem https://docs.djangoproject.com/pl/5.2/intro/tutorial01/. Uruchom wbudowany serwer www (polecenie znajdziesz w tutorialu lub w przykładzie poniżej zadań) i sprawdź czy projekt się uruchamia.
23 | 5. Skonfiguruj lokalne i zdalne repozytorium git. Przygotuj odpowiedni plik `.gitignore` dla projektu Django i wykonaj inicjalny commit oraz push do zdalnego repo. Przetestuj czy konfiguracja jest odpowiednia.
24 | 6. Zastanów się nad tematem Twojego projektu i schematem bazy danych, który będzie potrzebny do jej działania. Możesz również wybrać na tym etapie silnik bazy danych, na którym będziesz chciał osadzić swoje dane.
25 |
26 | ## Przydatne instrukcje do zadań
27 |
28 | ### Zadanie 1: Instalacja niezbędnego oprogramowania
29 |
30 | 1. **Zainstaluj Python**:
31 | - Sprawdź, czy Python jest zainstalowany na twoim komputerze. Możesz to zrobić, uruchamiając polecenie w terminalu:
32 | ```bash
33 | python --version
34 | ```
35 | - Jeśli nie masz Pythona zainstalowanego, pobierz go ze strony [oficjalnej Pythona](https://www.python.org/downloads/) i zainstaluj.
36 |
37 | 2. **Zainstaluj pip**: `pip` to menedżer pakietów Pythona. W większości instalacji Pythona `pip` jest domyślnie instalowany. Możesz to sprawdzić poleceniem:
38 | ```bash
39 | pip --version
40 | ```
41 |
42 | ## Zadanie 2: Stworzenie środowiska wirtualnego
43 |
44 | 1. **Utwórz folder projektu**:
45 | - Otwórz terminal i przejdź do folderu, w którym chcesz utworzyć projekt.
46 | - Utwórz nowy folder:
47 | ```bash
48 | mkdir myproject
49 | cd myproject
50 | ```
51 |
52 | 2. **Stwórz środowisko wirtualne**:
53 |
54 | - Uruchom polecenie, aby stworzyć wirtualne środowisko:
55 | ```bash
56 | python -m venv .venv
57 | # lub wykorzystując pakiet virtualenv
58 | python -m virtualenv .venv
59 | ```
60 |
61 | - Aktywuj środowisko wirtualne (korzystając z narzędzi takich jak PyCharm lub VSC ta operacja powinna się wykonać automatycznie w momencie uruchomienia okna terminala wewnątrz w/w narzędzi):
62 | - Na Windows:
63 | ```bash
64 | .venv\\Scripts\\activate
65 | ```
66 | - Na macOS/Linux:
67 | ```bash
68 | source .venv/bin/activate
69 | ```
70 | Utworzenie środowiska wirtualnego jak już rozumiemy cały proces może być wykonane również za pomocą GUI narzędzi PyCharm lub VSC. W przypadku tego pierwszego możliwe jest to na etapie tworzenia nowego projektu lub w dowolnym momencie pracy nad nim. W przypadku VSC mamy możliwość wykonać to po zainstalowaniu pluginu do obsługi Pythona i skorzystaniu z **Command palette**, które będzie zawierało odpowiednie opcje. Proces tez zostanie zaprezentowany przez prowadzącego w trakcie zajęć.
71 |
72 |
73 | ## Zadanie 3: Instalacja niezbędnych paczek
74 |
75 | 1. **Zainstaluj Django**:
76 | - W aktywowanym środowisku wirtualnym, upewnij się, że masz zainstalowany pakiet `django`:
77 | ```bash
78 | # wyświetlenie listy zainstalowanych paczek
79 | pip list
80 | # instalacja Django (najnowsza wersja major 5, minor 5.2)
81 | pip install django==5.2.*
82 | # lub konkretnie (w momencie pisania dokumentacji najnowsza wersja release)
83 | pip install django==5.2.7
84 | ```
85 |
86 | 2. **Rozwiązywanie problemów z instalacją**:
87 | - W razie problemów z instalacją, sprawdź oficjalną dokumentację [Django](https://docs.djangoproject.com/pl/5.2/intro/install/) w celu uzyskania wskazówek dotyczących instalacji.
88 |
89 | ## Zadanie 4: Przygotowanie pierwszego projektu i aplikacji Django
90 |
91 | 1. **Stwórz nowy projekt Django**:
92 | - W terminalu, upewnij się, że jesteś w katalogu głównym swojego projektu (blog). Następnie użyj polecenia:
93 | ```bash
94 | django-admin startproject blog
95 | ```
96 | - Przejdź do folderu projektu:
97 | ```bash
98 | cd blog
99 | ```
100 |
101 | 2. **Stwórz aplikację Django**:
102 | - W folderze projektu utwórz nową aplikację:
103 | ```bash
104 | python manage.py startapp posts
105 | ```
106 | - **Rozróżnienie**: Projekt Django to kontener dla aplikacji, podczas gdy aplikacja to konkretna część projektu, która wykonuje określone zadania (np. obsługa użytkowników, bloga itp.).
107 |
108 | 3. **Uruchom wbudowany serwer**:
109 | - Aby uruchomić serwer, użyj polecenia:
110 | ```bash
111 | python manage.py runserver
112 | ```
113 | - Sprawdź, czy aplikacja działa, otwierając przeglądarkę i wpisując adres `http://127.0.0.1:8000/`.
114 |
115 | ## Zadanie 5: Konfiguracja repozytorium Git
116 |
117 | 1. **Zainicjalizuj lokalne repozytorium**:
118 | - W folderze projektu, zainicjalizuj repozytorium Git:
119 | ```bash
120 | git init
121 | ```
122 |
123 | 2. **Przygotuj plik `.gitignore`**:
124 | - Utwórz plik `.gitignore` w katalogu głównym projektu. Dodaj następujące linie, aby zignorować pliki środowiska wirtualnego i inne pliki, które nie powinny być wersjonowane:
125 | ```
126 | .venv/
127 | *.pyc
128 | __pycache__/
129 | db.sqlite3
130 | ```
131 |
132 | 3. **Wykonaj inicjalny commit**:
133 | - Dodaj wszystkie pliki do repozytorium:
134 | ```bash
135 | git add .
136 | ```
137 | - Wykonaj commit:
138 | ```bash
139 | git commit -m "Initial commit"
140 | ```
141 |
142 | 4. **Skonfiguruj zdalne repozytorium**:
143 | - Utwórz zdalne repozytorium na platformie, takiej jak GitHub, GitLab lub Bitbucket.
144 | - Po utworzeniu zdalnego repozytorium, połącz je z lokalnym repozytorium:
145 | ```bash
146 | git remote add origin https://github.com/username/repo.git
147 | ```
148 |
149 | 5. **Wykonaj push do zdalnego repo**:
150 | - Prześlij zmiany do zdalnego repozytorium:
151 | ```bash
152 | git push -u origin main
153 | ```
154 | - Sprawdź, czy konfiguracja jest odpowiednia, przeglądając zdalne repozytorium.
--------------------------------------------------------------------------------
/lab_02/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## Lab 2
4 | ---
5 |
6 | **UWAGA!** Pamiętaj, aby na początku zajęć rozpocząć pracę na nowym branchu repozytorium!
7 |
8 | ### **1. Narzędzia administracyjne frameworka Django.**
9 |
10 | Django posiada narzędzie administracyjne w postaci skryptu `manage.py` oraz polecenia `django-admin` dzięki którym możemy wykonać wiele czynności administracyjnych, takich jak dodanie użytkownika administracyjnego, wykonanie migracji bazy danych, uruchomienie serwera i inne. Pełną listę poleceń można znaleźć w oficjalnej dokumentacji pod adresem: https://docs.djangoproject.com/pl/5.2/ref/django-admin/ oraz https://docs.djangoproject.com/en/5.2/ref/contrib/admin/
11 |
12 | Dodatkowe i przydatne narzędzia można dodać poprzez instalację zewnętrznych modułów, np. [django-admin-tools](https://github.com/django-admin-tools/django-admin-tools) (**archiwalnie istniał problem z instalacją z Django 4.2**),[django-debug-toolbar](https://django-debug-toolbar.readthedocs.io/en/latest/index.html) lub [django-extensions](https://pypi.org/project/django-extensions/).
13 |
14 | Jeżeli w trakcie poprzednich zajęć wykonana została tylko pierwsza część oficjalnego tutoriala, to aby móc wykonać ćwiczenia i zadania dla bieżącego laboratorium należy wykonać poniższe czynności.
15 |
16 | **Stworzenie schematu bazy danych**
17 |
18 | >**Uwaga** Jak zostało już wspomniane na pierwszych zajęciach praca w trakcie zajęć powinn iść dwutorowo, tj. potrzebne są dwa projekty Django, jeden do wykonania zadań w trakcie zajęć oraz jako środowisko eksperymentalne, a drugi projekt Django to projekt na zaliczenie. Od studenta zależy czy będzie to jedno dobrze zorganizowane repozytorium czy dwa oddzielne, jednak zalecane są oddzielne. Będzie to również miało wpływ na przygotowanie odpowiedniej konfiguracji połączenia z bazą danych przed wykonaniem operacji `migrate` (patrz dokumentacja: https://docs.djangoproject.com/en/5.2/ref/databases/).
19 | Istnieje również dość ryzykowna opcja polegająca na stworzeniu oddzielnych aplikacji wewnątrz projektu, z której jedna będzie aplikacją testową, a druga docelowym projektem, którymi dodatkowo można zarządzać z poziomu oddzielnych gałęzi repozytorium. Jest to jednak rozwiązanie dość problematyczne, a w szczególności wymagające dużej uwagi w trakcie przełączania między nimi.
20 |
21 | Aby podłączyć bazę danych MySQL do projektu Django, należy wykonać kilka kroków, w tym instalację odpowiedniego sterownika, konfigurację projektu Django oraz utworzenie bazy danych.
22 |
23 | Zalecane jest korzystać z bazy danych SQLite, gdyż nie będzie sprawiać to problemów w trakcie prezentacji projektu na zaliczenie.
24 |
25 | Poniższa operacja stworzy schematy dla wszystkich zainstalowanych aplikacji (zmienna `INSTALLED_APPS` w pliku `settings.py`). Jeżeli nie są niezbędne to można wybrane linie zakomentować lub dodać na końcu polecenia nazwy aplikacji, dla których chcemy stworzyć schemat.
26 |
27 | ```console
28 | # przygotowanie plików migracji
29 | python manage.py makemigrations
30 |
31 | # wykonanie migracji
32 | python manage.py migrate
33 | ```
34 |
35 | Warto przeczytać dokumentację dotyczącą tego polecenia, gdyż posiada ciekawe opcje, dość często potrzebne w trakcie początkowej pracy z modelem bazy danych i częstymi migracjami: https://docs.djangoproject.com/pl/5.2/ref/django-admin/#migrate
36 |
37 |
38 | **Stworzenie superużytkownika**
39 |
40 | ```console
41 | python manage.py createsuperuser
42 | ```
43 |
44 | Ten użytkownik jest niezbędny, aby możliwe było zalogowanie się do panelu administracyjnego i wykonywanie w nim czynności administracyjnych.
45 |
46 | Zaloguj się do panelu administracyjnego i sprawdź dostępne w nim opcje na tym etapie tworzenia aplikacji.
47 | Adres panelu przy domyślnych ustawieniach to: http://127.0.0.1:8000/admin
48 |
49 | ### 2. Schemat bazy danych.
50 |
51 | Każdy projekt potrzebuje jakiejś formy trwałego przechowywania choćby niewielkiej ilości danych, ale większość z nich przewiduje również powiększanie tych zbiorów przez aktywność użytkowników i rozwój aplikacji. Jeżeli nie dokonałeś jeszcze wyboru to zastanów się nad docelowym silnikiem bazy danych.
52 |
53 | Tworzenie schematu bazy na potrzeby projektu Django można przeprowadzić na dwa sposoby.
54 |
55 | **Sposób 1.**
56 | Tworzymy odpowiednie implementacje klasy `django.db.models.Model` z API Django (patrz **listing 1**), a następnie poprzez migrację tworzymy schemat w docelowej bazie.
57 |
58 | **Sposób 2**
59 | Iżynieria wsteczna (ang. reverse engineering). Schemat bazy danych możemy przygotować bezpośrednio poprzez polecenia SQL lub narzędzia graficzne, a następnie poleceniem `manage.py inspectdb` wygenerować kod w języku Python zgodny z deklaracją, którą należy przygotować postępując sposobem pierwszym. Ten kod zostanie wyświetlony w konsoli i można strumień przekierować do pliku. Przykład poniżej.
60 |
61 | ```console
62 | # dopisanie wyjścia polecenia po lewej stronie znaków >> do pliku
63 | manage.py inspectdb >> models.py
64 | ```
65 |
66 | ### 3. Modele w Django.
67 |
68 | **UWAGA!**
69 | Tworzymy w projekcie z labu numer 1 nową aplikację o nazwie `blog`, w której implementujemy kolejne przykłady zaprezentowane w materiałach.
70 |
71 | > Dokumentacja: https://docs.djangoproject.com/pl/5.2/topics/db/models/
72 |
73 | Definicje modeli dodajemy w pliku `blog/posts/models.py`.
74 | Poniżej zaprezentowane zostaną dwa przykładowe modele, przygotowanie migracji, propagacje modeli na bazę danych oraz zarządzanie nimi z poziomu panelu administracyjnego.
75 |
76 | __*Listing 1:*__
77 | ```python
78 |
79 | class Category(models.Model):
80 | name = models.CharField(max_length=60)
81 |
82 |
83 | class Topic(models.Model):
84 | name = models.CharField(max_length=60)
85 | category = models.ForeignKey(Category, on_delete=models.CASCADE)
86 | created = models.DateTimeField(auto_now_add=True)
87 |
88 | ```
89 |
90 | Jeżeli chcemy aby mechanizm migracji wykrywał stworzone modele w naszej aplikacji i migrował je na bazę danych to należy dodać naszą aplikację do zmiennej `INSTALLED_APPS` w pliku `settings.py`:
91 |
92 | ```python
93 | INSTALLED_APPS = [
94 | 'django.contrib.admin',
95 | 'django.contrib.auth',
96 | 'django.contrib.contenttypes',
97 | 'django.contrib.sessions',
98 | 'django.contrib.messages',
99 | 'django.contrib.staticfiles',
100 | # 'posts.apps.PostsConfig',
101 | # lub
102 | 'posts'
103 | ]
104 | ```
105 |
106 | Następnie trzeba przygotować plik migracji poleceniem `manage.py makemigrations`, który przeanalizuje kod modeli i pozwoli nam na tym etapie rozwiązać ewentualne problemy ze spójnością danych, błędami w kodzie, wartościami null i innymi problemami, którymi nie będziemy musieli zajmować się na etapie propagacji modeli na schemat bazy danych.
107 |
108 | Ostatni krok to wykonanie migracji poprzez polecenie `manage.py migrate`, które stworzy odpowiednie tabele w domyślnej bazie danych (zdefiniowana w pliku `settings.py`).
109 |
110 | #### 3.1 Rejestracja modeli w panelu administracyjnym Django.
111 |
112 | Po wykonaniu migracji modele nie będą domyślnie widoczne w panelu administracyjnym Django.
113 | Należy je najpierw zarejestrować w pliku `admin.py` znajdującym się w folderze naszej aplikacji:
114 |
115 | ```python
116 | # modele musimy zaimportować
117 | from .models import Category, Topic
118 |
119 | # a następnie zarejestrować (pokazano najprostszy przypadek)
120 | admin.site.register(Category)
121 | admin.site.register(Topic)
122 | ```
123 |
124 | Odświeżając teraz widok w penelu administracyjnym powinniśmy mieć możliwość zarządzania obiektami zarejestrowanych modeli.
125 |
126 |
127 | **ZADANIA**
128 |
129 | 1. Dodaj pole `description` do modelu `Category` o typie `TextField`. Przygotuj plik migracji (`makemigrations`), a następnie wykonaj migrację i sprawdź czy zmiany zostały propagowane na bazę (np. poprzez panel administracyjny lub przeglądając strukturę bazy danych). Przejrzyj zawartość pliku migracji.
130 | 2. Za pomocą polecenia `showmigrations` wylistuj wszystkie migracje dla danej aplikacji, a następnie sprawdzając w dokumentacji działanie polecenia `migrate` wycofaj ostatnią migrację.
131 | 3. Zainstaluj pakiet `django-debug-toolbar` i skonfiguruj go (link na początku tego pliku z materiałami).
132 | 4. Poprzez panel administracyjny przetestuj dodanie, modyfikację i usunięcie instancji modeli `Category` oraz `Topic`. Przeanalizuj co się dzieje w aplikacji poprzez `django debug toolbar`.
133 | 5. Zatwierdź niezbędne zmiany w repozytorium i wypchnij je do zdalnego repozytorium. Jeżeli nie zostało to jeszcze wykonane, należy dodać prowadzącego jako kolaboratora repozytorium w celu łatwiejszego dostepu do kodu projektu rozwijanego na zajęciach w celach archiwizacji oraz ewentualnej pomocy w rozwiązywaniu problemów w kodzie.
134 |
135 |
136 | ### Dodatkowe narzędzia i materiały.
137 |
138 | * Do obsługi wielu źródeł baz danych może przydać się darmowe narzędzie o nazwie DBeaver, które posiada również możliwość tworzenia schematów bazy danych a następnie generowania poleceń SQL z takiego schematu. Więcej: https://dbeaver.com/2022/07/07/forward-engineering-with-erd/
139 |
--------------------------------------------------------------------------------
/lab_04/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## Lab 4 - Django Rest Framework i serializacja danych.
4 | ---
5 |
6 |
7 | `Serializer` pozwala na konwersję złożonych danych na rodzime typy danych w języku Python, które można następnie łatwo przekształcić w JSON, XML lub inne typy treści. Serializatory zapewniają również deserializację, umożliwiając przekształcenie przeanalizowanych danych z powrotem w złożone typy po uprzednim sprawdzeniu poprawności danych przychodzących.
8 |
9 | `Serializer` w środowisku REST działa bardzo podobnie do klas `Form` i `ModelForm` w Django. W naszych projektach będziemy korzystać z:
10 |
11 | - `Serializer` - ogólny sposób kontrolowania requestów,
12 | - `ModelSerializer` - sprawdzanie modeli, inicjalizacja.
13 |
14 | Po dokładne informacje o serializacji odsyłamy do informacji z wykładu oraz [dokumentacji DRF](https://www.django-rest-framework.org/api-guide/serializers/).
15 |
16 | ## Przykład klasy do serializacji danych
17 |
18 | **__Listing 1__**
19 | ```python
20 | from rest_framework import serializers
21 | from .models import Person, Team, MONTHS, SHIRT_SIZES
22 |
23 |
24 | class PersonSerializer(serializers.Serializer):
25 |
26 | # pole tylko do odczytu, tutaj dla id działa też autoincrement
27 | id = serializers.IntegerField(read_only=True)
28 |
29 | # pole wymagane
30 | name = serializers.CharField(required=True)
31 |
32 | # pole mapowane z klasy modelu, z podaniem wartości domyślnych
33 | # zwróć uwagę na zapisywaną wartość do bazy dla default={wybór}[0] oraz default={wybór}[0][0]
34 | # w pliku models.py SHIRT_SIZES oraz MONTHS zostały wyniesione jako stałe do poziomu zmiennych skryptu
35 | # (nie wewnątrz modelu)
36 | shirt_size = serializers.ChoiceField(choices=SHIRT_SIZES, default=SHIRT_SIZES[0][0])
37 | miesiac_dodania = serializers.ChoiceField(choices=MONTHS.choices, default=MONTHS.choices[0][0])
38 |
39 | # odzwierciedlenie pola w postaci klucza obcego
40 | # przy dodawaniu nowego obiektu możemy odwołać się do istniejącego poprzez inicjalizację nowego obiektu
41 | # np. team=Team({id}) lub wcześniejszym stworzeniu nowej instancji tej klasy
42 | team = serializers.PrimaryKeyRelatedField(queryset=Team.objects.all())
43 |
44 | # przesłonięcie metody create() z klasy serializers.Serializer
45 | def create(self, validated_data):
46 | return Person.objects.create(**validated_data)
47 |
48 | # przesłonięcie metody update() z klasy serializers.Serializer
49 | def update(self, instance, validated_data):
50 | instance.name = validated_data.get('name', instance.name)
51 | instance.shirt_size = validated_data.get('shirt_size', instance.shirt_size)
52 | instance.miesiac_dodania = validated_data.get('miesiac_dodania', instance.miesiac_dodania)
53 | instance.team = validated_data.get('team', instance.team)
54 | instance.save()
55 | return instance
56 | ```
57 |
58 | Przetestowanie działania serializatora możemy również przeprowadzić z poziomu shella Django. Przykład kolejnych operacji poniżej.
59 |
60 | _**Listing 2**_
61 | ```python
62 |
63 | from ankiety.models import Person
64 | from ankiety.serializers import PersonSerializer
65 | from rest_framework.renderers import JSONRenderer
66 | from rest_framework.parsers import JSONParser
67 |
68 | # 1. stworzenie nowej instancji klasy Person (opcjonalne, mamy panel admin do tego również)
69 | person = Person(name='Adam', miesiac_dodania=1)
70 | # utrwalenie w bazie danych
71 | person.save()
72 |
73 | # 2. inicjalizacja serializera
74 | serializer = PersonSerializer(person)
75 | serializer.data
76 | # output - natywny typ danych Pythona (dictionary)
77 | {'id': 16, 'name': 'Adam', 'shirt_size': ('S', 'Small'), 'miesiac_dodania': 1, 'team': None}
78 |
79 | # warto również zwrócić uwagę na wartość zmiennej shirt_size, która przyjęła wartość jako krotkę (która została zamieniona na typ str), gdyż w modelu został domyślny wybór określony jako SHIRT_SIZE[0] co jest pierwszą krotką dla tej kolekcji o wartości ('S', 'Small')
80 | # zamiana na SHIRT_SIZE[0][0] wskazałaby wartość 'S' i powinna również działać poprawnie dla modelu Person
81 | # output po zmianach w modelu
82 | # {'id': 19, 'name': 'Genowefa', 'shirt_size': 'S', 'miesiac_dodania': 1, 'team': None}
83 |
84 | # 3. serializacja danych do formatu JSON
85 | content = JSONRenderer().render(serializer.data)
86 | content
87 |
88 | # output
89 | b'{"id":16,"name":"Adam","shirt_size":"S","miesiac_dodania":1,"team":null}'
90 |
91 | # w takiej formie możemy przesłać obiekt (lub cały graf obiektów) przez sieć i po "drugiej stronie" dokonać deserializacji odtwarzając graf i stan obiektów
92 |
93 | import io
94 |
95 | stream = io.BytesIO(content)
96 | data = JSONParser().parse(stream)
97 |
98 | # tworzymy obiekt dedykowanego serializera i przekazujemy sparsowane dane
99 | deserializer = PersonSerializer(data=data)
100 | # sprawdzamy, czy dane przechodzą walidację (aktualnie tylko domyślna walidacja, dedykowana zostanie przedstawiona na kolejnych zajęciach)
101 | deserializer.is_valid()
102 | # output
103 | # False
104 |
105 | # to oznacza pojawienie się błędu walidacji
106 | deserializer.errors
107 | # output
108 | # {'team': [ErrorDetail(string='Pole nie może mieć wartości null.', code='null')]}
109 |
110 | # w samym modelu określone są dwa atrybuty null=True, blank=True, ale jak widać serializer nie bierze tego pod uwagę
111 | # musimy w klasie PersonSerializer zmodyfikować wartość dla pola team
112 | # dodając atrybut allow_null=True i uruchomić całe testowanie raz jeszcze
113 |
114 | # aby upewnić się w jaki sposób wyglądają pola wczytanego serializera/deserializera, możemy wywołać zmienną deserializer.fields, aby wyświetlić te dane
115 | deserializer.fields
116 |
117 | # lub
118 | repr(deserializer)
119 |
120 | # po powyższych zmianach walidacja powinna już się powieść
121 | # możemy sprawdzić jak wyglądają dane obiektów po deserializacji i walidacji
122 | deserializer.validated_data
123 | # output
124 | # OrderedDict([('name', 'Adam'), ('shirt_size', 'S'), ('miesiac_dodania', 1), ('team', None)])
125 |
126 | # oraz utrwalamy dane
127 | deserializer.save()
128 | # sprawdzamy m.in. przyznane id
129 | deserializer.data
130 | ```
131 |
132 |
133 | W przykładzie powyżej widać sporo nadmiarowej pracy w stosunku do zdefiniowanych wcześniej modeli (możemy oczywiście chcieć serializować również inne obiekty niż modele z naszego projektu) i na pewno pojawiła się refleksja - "Czy można wykorzystać jakąś część kodu z klas modeli?". Otóż można, wykorzystując klasę `ModelSerializer` z Django Rest Framework.
134 |
135 |
136 | ## Przykład klasy do serializacji danych (dziedziczącej po klasie ModelSerializer)
137 |
138 | Dokumentacja: https://www.django-rest-framework.org/api-guide/serializers/#modelserializer
139 |
140 | _**Listing 3**_
141 | ```python
142 | class PersonModelSerializer(serializers.ModelSerializer):
143 | class Meta:
144 | # musimy wskazać klasę modelu
145 | model = Person
146 | # definiując poniższe pole możemy określić listę właściwości modelu,
147 | # które chcemy serializować
148 | fields = ['id', 'name', 'miesiac_dodania', 'shirt_size', 'team']
149 | # definicja pola modelu tylko do odczytu
150 | read_only_fields = ['id']
151 | ```
152 |
153 | Powyższa klasa serializatora wykorzystuje wszystkie własności pól z klasy modelu, co znacznie zmniejsza ilość powielanego kodu i redukuje czas i ilość pracy niezbędny do dokonania zmian walidacji pól modelu. Te cechy zostaną pobrane do serializatora z definicji modelu, więc nie musimy ich przechowywać w dwóch miejscach.
154 |
155 | Testowanie kodu odbywa się adekwatnie do przykładu z listingu nr 1.
156 |
157 |
158 | # Zadania
159 |
160 | Celem ćwiczeń będzie stworzenie klas odpowiedzialnych za serializację danych w naszym projekcie API. Następujące polecenia powinny być wykonane dla każdego modelu w projekcie, do którego będziemy mieli dostęp zewnętrzny (przez dostęp do endpointu, np. dodanie nowej osoby do systemu).
161 |
162 |
163 | 1. Tworzymy nowy branch na potrzeby tego labu.
164 | 2. Zainstaluj moduł `djangorestframework` do środowiska wirtualnego i skonfiguruj DRF.
165 | 3. W **aplikacji**, w której znajduje się nasz model otwieramy/tworzymy plik `serializers.py` lub pakiet `serializers/`, a tam definiujemy nasze klasy serializatorów.
166 | 4. Napisz 1 klasę serializatora dla swojej aplikacji dziedziczącą po klasie `serializers.Serializer`.
167 | 5. Resztę modeli zaimplementuj w postaci serializatorów `ModelSerializer` jeżeli to możliwe.
168 | 6. Napisz kod prezentujący wykorzystanie wybranych dwóch serializatorów (patrz listing 2) ze swojej aplikacji i umieść go w pliku markdown o nazwie `drf_serializer_test.md` w folderze `./{twoja_aplikacja}/docs/` (utwórz folder `docs`).
169 |
170 |
171 | Do konsoli django można również przekazać cały plik z kodem testującym przekazując go jako potok wejściowy:
172 | ```console
173 | python manage.py shell < ./sciezka/do_pliku.py
174 | ```
175 |
176 | Należy jednak pamiętać o tym, że w ten sposób musimy wykonywać importy z podaniem nazwy aplikacji np. `from ankiety.models import Person`, a nie `from .models import Person`.
177 |
178 | Minusem jest niestety dość nieczytelny output, gdzie znaczniki wyjścia konsoli Pythona (czyli >>>) mogą się wielokrotnie powtarzać.
179 |
180 |
181 | Dodatkowe wskazówki:
182 |
183 | * Nadpisujemy odpowiednie metody `create`, `update` itp. w momencie gdy musimy zapisać obiekty w inny niż domyślny sposób (np. chcemy dodać aktualnie zalogowanego użytkownika jako właściciela stworzonego modelu, chcemy zamienić wielkość znaków, usunąć jakieś znaki z tekstu itp.).
184 |
--------------------------------------------------------------------------------
/lab_09/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## 1. Szablony stron w Django.
4 |
5 | Framework Django dostarcza mechanizmu szablonów, dzięki któremu tworzenie modułowych stron opartych o HTML i CSS jest dużo prostsze niż tworzenie ich oddzielnie dla każdego z widoków w aplikacji. Wyobraź to sobie jako szablon, który definiuje różne obszary na naszej stronie np. nagłówek, gdzie znajduje się logo, może nawigacja. Poniżej możemy mieć dodatkowe obszary np. w układzie kolumnowym albo kafelki. Odwiedzając kolejne podstrony cała strona zazwyczaj nie zmienia się diametralnie, ale jest podmieniana tylko treść w niektórych obszarach. To znacznie ułatwia zarządzanie samym szablonem, gdyż zmniejsza ilość pracy w celu zmiany głównego szablonu dla całego serwisu, ale również ułatwia definicję kolejnych widoków i treści, która ma zostać podmieniona tylko w wybranych obszarach szablonu.
6 |
7 | Cały proces od przygotowania szablonu (-ów) do finalnego wyświetlenia jednego z widoków w ramach tego szablonu będzie wymagał sporo pracy, więc zostanie opisany w kolejnych krokach.
8 |
9 | **Krok 1 - Przygotowanie odpowiedniej struktury folderów i plików w projekcie.**
10 |
11 | Najpierw przygotujemy strukturę katalogów oraz kilka pustych plików HTML, w których umieścimy szablon oraz póki co dwie podstrony. Struktur została zaprezentowana poniżej.
12 |
13 |
14 | ```console
15 |
16 | blog
17 | - posts
18 | - templates
19 | - posts
20 | - category
21 | - detail.html
22 | - list.html
23 | - base.html
24 | ```
25 |
26 | **Krok 2 - stworzenie szablonu bazowego.**
27 |
28 | W pliku `base.html` umieszczamy poniższą zawartość.
29 |
30 | _**Listing 1**_
31 | ```html
32 |
33 |
34 |
35 | {% block title %}{% endblock %}
36 |
37 |
38 |
39 | Aplikacja blog/posts
40 |
41 |
42 | {% block content %}
43 | {% endblock %}
44 |
45 |
46 |
Panel boczny
47 |
48 |
49 |
50 | ```
51 |
52 | Znaczniki `{}`, które znajdują się w treści szablonu są specjalnymi znacznikami silnika szablonów Django i oznaczają:
53 | * `{% znacznik %}` - znacznik szablonu
54 | * `{{ zmienna }}` - zmienna szablonu
55 | * `{{ zmienna|filtr }}` - filtr zmiennej
56 |
57 | W szablonie powyżej zdefiniowane zostały bloki `title` oraz `content`, których zawartość będziemy mogli podmieniać w poszczególnych podwidokach nie zmieniając całej reszty szablonu. Aktualnie nasz szablon nie korzysta z żadnego pliku ze stylami, zajmiemy się tym później.
58 |
59 | **Krok 3 - przygotowanie widoku dla listy obiektów `Category`.**
60 |
61 | Teraz umieszczamy poniższą treść w pliku `templates\posts\category\list.html`.
62 |
63 | _**Listing 2**_
64 | ```html
65 | {% extends "posts\base.html" %}
66 |
67 | {% block title %}Lista obiektów Category{% endblock %}
68 |
69 | {% block content %}
70 | Lista kategorii:
71 | {% for category in categories %}
72 |
Nazwa: {{ category.name }}
73 |
Opis: {{ category.description }}
74 |
75 | {% endfor %}
76 | {% endblock %}
77 | ```
78 |
79 | Kilka słów wyjaśnień do powyższego pliku.
80 | Znacznik `{% extends "posts\base.html" %}` informuje silnik szablonów o tym, że ten plik rozszerza szablon wskazany w ścieżce, tzn. że jeżeli zdefiniujemy w nim znaczniki bloków o tej samej nazwie co w szablonie, zostaną one podmienione na zawartość bloków zdefiniowanych tutaj jeszcze przed wyświetleniem w przeglądarce. Dzięki temu możemy zamieniać w poszczególnych widokach tylko wybrane fragmenty.
81 | Znacznik `{% for category in categories %}` oznacza uruchomienie pętli `for` przed wyświetleniem szablonu, która oczekuje istnienia w przestrzeni tego szablonu (przekażemy ją w definicji widoku) zmiennej `categories`, którą można iterować (przechodzić po jej elementach), gdzie przy każdym przejściu pobierany będzie jeden obiekt typu `Category` i zapisywany do zmiennej lokalnej `category` tej pętli i powtarzane będą kolejne linie, aż do znacznika `{% endfor %}`.
82 | Zmienne takie jak `{{ category.name }}` odwołują się do własności pojedynczego obiektu `category` i w szablonie zostaną zamienione na ich postać łańcuchową (w uproszczeniu tekstową, tak jakbyśmy na każdej z nich wywołali funkję `print()`, a właściwie `__str()__`). Wszystko co zdefiniowane w pętli, zostanie wywołane i powielone tyle razy ile obiektów znajdzie się w zmiennej `categories`.
83 |
84 | **Krok 4 - zmiana definicji widoków.**
85 |
86 | Teraz musimy zmienić nieco definicję widoków, tak aby korzystały z odpowiednich szablonów, które stworzyliśmy. W pliku `posts\views.py` zmieniamy definicję widoku funkcyjnego `category_view` na poniższy.
87 |
88 | _**Listing 3**_
89 | ```python
90 | # dodajemy brakujący import
91 | from django.shortcuts import render
92 |
93 | def category_list(request):
94 | # pobieramy wszystkie obiekty Person z bazy poprzez QuerySet
95 | categories = Category.objects.all()
96 |
97 | return render(request,
98 | "posts/category/list.html",
99 | {'categories': categories})
100 | ```
101 |
102 |
103 | Widok na pewno sam w sobie nie jest imponujący pod względem wizualnym, ale wiemy już jak tworzyć proste szablony i przekazywać do nich dane pobrane z naszej bazy.
104 |
105 | Na koniec dokonamy jeszcze modyfikacji pliku z szablonem, aby możliwe było dodanie styli CSS i zmiana wyglądu strony.
106 |
107 | Modyfikacja pliku `base.html`.
108 |
109 | _**Listing 4**_
110 | ```html
111 | {% load static %}
112 |
113 |
114 |
115 | {% block title %}{% endblock %}
116 |
117 |
118 |
119 |
129 |
130 |
131 | ```
132 |
133 | Dodaliśmy mechanizm wczytywania plików statycznych przez Django, które to mogą być plikami ze stylami, obrazami, dołączanymi bibliotekami JavaScript.
134 |
135 | Teraz stworzymy jeszcze wymieniony w nagłówku szablonu plik `posts.css`. Obsługa plików statycznych przez Django odbywa się w specyficzny sposób i domyślnie powinny być umieszczane w folderze `static` w każdej aplikacji z osobna. Tworzymy więc folder `static` a w nim folder `css`, w którym umieszczamy plik `posts.css`.
136 | Uruchom ponownie serwer i przejdź na widok listy wszystkich obiektów `Category` i sprawdź w konsoli, gdzie uruchomiony jest serwer czy nie pojawia się błąd 404 protokołu HTTP (NOT FOUND) przy ścieżce do pliku css np. tak
137 | ```console
138 | [28/Nov/2025 21:16:47] "GET /static/css/post.css HTTP/1.1" 404 1798
139 | ```
140 |
141 | Może to oznaczać błąd w zdefiniowanej ścieżce.
142 |
143 | Teraz przygotujemy widok dla pojedynczego obiektu typu `Category`, którego defininicja będzie wymagała przekazywania przez adres URL wartości parametru `id`, dla którego konkretny obiekt `Category` zostanie pobrany z bazy danych.
144 |
145 | _**Listing 5**_
146 |
147 | Zawartość pliku `template\category\detail.html`
148 | ```html
149 | {% extends "posts\base.html" %}
150 |
151 | {% block title %}{{ category.name }}{% endblock %}
152 |
153 | {% block content %}
154 |
Nazwa: {{ category.name }}
155 |
Opis: {{ category.description }}
156 | {% endblock %}
157 | ```
158 |
159 | Teraz dodanie widoku w pliku `posts\views.py`
160 |
161 | _**Listing 6**_
162 | ```python
163 | def category_detail(request, id):
164 | # pobieramy konkretny obiekt Category
165 | category = Category.objects.get(id=id)
166 |
167 | return render(request,
168 | "posts/category/detail.html",
169 | {'category': category})
170 | ```
171 |
172 | I dodajemy mapowanie URL na nowy widok w pliku `posts\urls.py`
173 |
174 | _**Listing 7**_
175 |
176 | ```python
177 | from django.urls import path
178 |
179 | from . import views
180 |
181 | urlpatterns = [
182 | path("welcome", views.welcome_view),
183 | path("categories", views.category_list),
184 | path("category/", views.category_detail),
185 | ]
186 | ```
187 |
188 | Definicja `"category/"` oznacza, że adres pasujący do schematu `.../category/liczba_całkowita` będzie mapowany na widok `category_detail`. Jest to jeden ze sposobów przekazywania wartości parametrów do naszej aplikacji.
189 |
190 | Teraz w przeglądarce po wpisaniu adresu http://127.0.0.1:8000/posts/category/1 powinniśmy zobaczyć widok dla obiektu typu `Category` o id=1 o ile istnieje w bazie. Jeżeli obiekt o podanym id nie znajduje się w bazie zgłoszony zostanie wyjątek `models.ModelNotFound`, który nieobsłużony da nam dość jasną odpowiedź co jest nie tak (o ile pracujemy z włączonym trybem debug).
191 |
192 | Możemy temu zaradzić dodając obsługę takiej ewentualności. Zmodyfikowana postać widoku `category_detail`:
193 |
194 | _**Listing 8**_
195 |
196 | ```python
197 | # dodajemy brakujący import na początku pliku (modyfikacja)
198 | from django.http import Http404, HttpResponse
199 |
200 | def category_detail(request, id):
201 | # pobieramy konkretny obiekt Category
202 | try:
203 | category = Category.objects.get(id=id)
204 | except Category.DoesNotExist:
205 | raise Http404("Obiekt Category o podanym id nie istnieje")
206 |
207 | return render(request,
208 | "posts/category/detail.html",
209 | {'category': category})
210 | ```
211 |
212 | **Ćwiczenia do samodzielnego wykonania**
213 |
214 | **Zadanie 1**
215 |
216 | W ramach tego zadania stwórz:
217 | * widok listy oraz detali dla modelu `Topic` oraz `Post`
218 |
219 | **Zadanie 2**
220 |
221 | Stwórz widok, który będzie wyświetlał wszystkie posty dla danego tematu (`Topic`) w kolejności od najnowszych do najstarszych (pomińmy fakt, że tu mogłaby się przydać paginacja).
222 |
223 | **Zadanie 3**
224 |
225 | Dodatkowo w pliku `posts.css` zdefiniuj style, które nadadzą stronie trochę bardziej atrkacyjny widok.
--------------------------------------------------------------------------------
/lab_07/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## Lab 7 - Uprawnienia w aplikacji Django oraz w Django Rest Framework.
4 |
5 | > **Materiały uzupełniające:**
6 | > * Ciekawy rtykuł o uprawnieniach dla Django: https://realpython.com/manage-users-in-django-admin/ (UWAGA: linki odnoszą do dokumentacji dla wersi 2.x Django)
7 | > * Django i uprawnienia: https://docs.djangoproject.com/pl/5.2/topics/auth/default/#permissions-and-authorization
8 |
9 |
10 | ## 1. Uprawnienia, a panel administracyjny Django.
11 |
12 | Django posiada wbudowany moduł `auth`, dzięki któremu dostarczany jest mechanizm uwierzytelniania i autoryzacji dla użytkowników aplikacji. Jeżeli aplikacje `django.contrib.admin` oraz `django.contrib.auth` są zainstalowane to w ramach panelu administracyjnego możliwe jest tworzenie użytkowników, grup i przypisywanie im uprawnień.
13 |
14 | Ogólna zasada zarządzania uprawnieniami jest taka, iż powinniśmy uprawnienia przypisywać do grup, a nie bezpośrednio do użytkowników. To pozwala na tworzenie różnych poziomów uprawnień (możemy przypisać użytkownika do wielu grup) i zdecydowanie łatwiejszego nimi zarządzania (pojawienie się nowego użytkownika danego działu nie wymaga kopiowania pojedynczych uprawnień tylko przypisania go do odpowiedniej grupy).
15 |
16 | Domyślne uprawnienia dla modeli w panelu administracyjnym, będą kontrolowane przez ten panel dla użytkowników w zespole (atrybut użytkownika), którym ten atrybut umożliwia zalogowanie się w panelu. Pozostałe, stworzone przez nas uprawnienia można przypisywać poprzez panel, ale nie zadziałają z automatu i ich reguły muszą być określone na poziomie np. modeli administracyjnych (`ModelAdmin`). Właściwe wykorzystanie tych właściwości i wykorzystanie własnej implementacji modelu użytkownika (przesłonięcie wbudowanego modelu `User`) pozwala zbudować całkiem funkcjonalną aplikację opartą o Django admin.
17 |
18 | ## 2. Uprawnienia a modele Django.
19 |
20 | Django posiada wbudowany mechanizm podstawowych uprawnień dla każdego modelu, który w aplikacji zostanie utworzony. Dla każdego modelu zostaną utworzone cztery prawa:
21 |
22 | * `add` - pozwala na stworzenie nowej instancji modelu,
23 | * `delete` - pozwala na usunięcie instancji modelu,
24 | * `change` - pozwala na aktualizację instancji modelu,
25 | * `view` - pozwala na wyświetlenie instancji obiektu.
26 |
27 | Aby całość funkcjonowała poprawnie w ekosystemie projektu nazwy uprawnień nadawane są wg. konwencji:
28 | `._` np. `ankiety.change_person`.
29 |
30 | > **Każdy superuser posiada wszystkie prawa, chociaż bliższe prawdy jest stwierdzenie, że tak na prawdę te uprawnienia nie są dla niego sprawdzane w momencie użycia metody `has_perm(uprawnienie)`, które dla tekiego uzytkownika zawsze zwraca wartość `True`.**
31 |
32 |
33 | Samo istnienie uprawnień nie powoduje, że w każdym miejscu aplikacji działa mechanizm ich weryfikacji, jeżeli na danym modelu odbywa się jedna z operacji CRUD. Jedynym miejscem, w którym się to odbywa automatycznie jest panel administracyjny.
34 |
35 | W każdym innym miejscu musimy zaimplementować metody sprawdzające posiadanie przez użytkownika wykonującego daną akcję posiadanie przez niego stosownych uprawnień.
36 |
37 | **_Listing 1_**
38 | ```python
39 | from django.core.exceptions import PermissionDenied
40 |
41 | def person_view(request, pk):
42 | if not request.user.has_perm('ankiety.view_person'):
43 | raise PermissionDenied()
44 | try:
45 | person = Person.objects.get(pk=pk)
46 | return HttpResponse(f"Ten użytkownik nazywa się {person.name}")
47 | except Person.DoesNotExist:
48 | return HttpResponse(f"W bazie nie ma użytkownika o id={pk}.")
49 | ```
50 |
51 | Można wykorzystać również dekoratory na wzór:
52 |
53 | **_Listing 2_**
54 |
55 | ```python
56 | from django.contrib.auth.decorators import permission_required
57 |
58 | @permission_required('ankiety.view_person')
59 | def person_view(request, pk):
60 | try:
61 | person = Person.objects.get(pk=pk)
62 | return HttpResponse(f"Ten użytkownik nazywa się {person.name}")
63 | except Person.DoesNotExist:
64 | return HttpResponse(f"W bazie nie ma użytkownika o id={pk}.")
65 | ```
66 |
67 | Oprócz wbudowanych uprawnień dla modeli możliwe jest również zdefiniowanie dodatkowych uprawnień w klasie wewnętrznej `Meta` każdego modelu.
68 |
69 | **_Listing 3_**
70 |
71 | ```python
72 | class Person(models.Model):
73 | ...
74 | class Meta:
75 | permissions = [
76 | ("change_person_owner", "Pozwala przypisać inną osobę do obiektu Person."),
77 | ("change_assign_to_team", "Pozwala przypisać osobę do innej drużyny."),
78 | ]
79 | ```
80 | Aby takie uprawnienia pojawiły się w panelu administracyjnym i było możliwe ich wykorzystanie w projekcie należy wykonać proces migracji, gdyż funkcja tworząca uprawnienia jest powiązana z sygnałem `post_migrate`.
81 | Implementacja logiki tych uprawnień spoczywa w całości na programiście.
82 |
83 | Możliwe jest również weryfikowanie uprawnień na poziomie szablonów widoków Django (jeżeli to jest nasza docelowa technologia wizualizacji dla projektu) odwołując się do zmiennej `perms` w szablonie.
84 |
85 | **_Listing 4_**
86 | ```python
87 | {% if perms.ankiety.delete_person %}
88 |
89 | {% endif %}
90 | ```
91 |
92 | ## 3.Uprawnienia a Django Rest Framework
93 |
94 | Django Rest Framework dostarcza kilka wbudowanych uprawnień, z których część została przedstawiona na poprzednich zajęciach (np. `IsAuthenticated`).
95 |
96 | Pozostałe zostały opisane tutaj: https://www.django-rest-framework.org/api-guide/permissions/#api-reference
97 |
98 | **Wykorzystanie istniejących uprawnień modeli w DRF.**
99 |
100 | Dokumentacja: https://www.django-rest-framework.org/api-guide/permissions/#djangomodelpermissions
101 |
102 | Z racji tego, że aktualnie nie ma oficjalnego rozwiązania pozwalającego na wykorzystanie `DjangoModelPermissions` w przypadku wykorzystania widoków funkcyjnych (to te, gdzie używamy dekoratora `@api_view`) należy niezbędną logikę widoków dla DRF przepisać na class based views.
103 |
104 | > **UPDATE:** Można jednak obejść problem wykorzystania `DjangoModelPermissions` w widokach funkcyjnych ustawiając ten mechanizm jako główny w pliku `settings.py`, a następnie w widokach przesłaniając go innymi wartościami dekoratora `@permission_classes`
105 |
106 | Wpis w `settings.py`:
107 | >**UWAGA! - tu użyta klasa rozszerzająca DjangoModelPermissions - patrz listing 6).**
108 | ```python
109 | REST_FRAMEWORK = {
110 | 'DEFAULT_PERMISSION_CLASSES': (
111 | 'ankiety.permissions.CustomDjangoModelPermissions',
112 | )
113 | }
114 | ```
115 | **_Listing 4_**
116 | ```python
117 | # i teraz widok funkcyjny może wyglądać tak
118 | @api_view(['GET'])
119 | @permission_classes([IsAuthenticated])
120 | @authentication_classes([BearerTokenAuthentication])
121 | def person_detail(request, pk):
122 |
123 | """
124 | :param request: obiekt DRF Request
125 | :param pk: id obiektu Person
126 | :return: Response (with status and/or object/s data)
127 | """
128 |
129 | if request.method == 'GET':
130 | try:
131 | person = Person.objects.get(pk=pk)
132 | except Person.DoesNotExist:
133 | return Response(status=status.HTTP_404_NOT_FOUND)
134 |
135 | serializer = PersonSerializer(person)
136 | return Response(serializer.data)
137 |
138 | ```
139 |
140 | Przykład dla modelu `Team` poniżej.
141 |
142 | **_Listing 5**
143 |
144 | ```python
145 | class TeamDetail(APIView):
146 | authentication_classes = [BearerTokenAuthentication]
147 | permission_classes = [IsAuthenticated, CustomDjangoModelPermissions]
148 |
149 | # dodanie tej metody lub pola klasy o nazwie queryset jest niezbędne
150 | # aby DjangoModelPermissions działało poprawnie (stosowny błąd w oknie konsoli
151 | # nam o tym przypomni)
152 | def get_queryset(self):
153 | return Team.objects.all()
154 |
155 | def get_object(self, pk):
156 | try:
157 | return Team.objects.get(pk=pk)
158 | except Team.DoesNotExist:
159 | raise Http404
160 |
161 | def get(self, request, pk, format=None):
162 | team = self.get_object(pk)
163 | serializer = TeamSerializer(team)
164 | return Response(serializer.data)
165 |
166 | def put(self, request, pk, format=None):
167 | team = self.get_object(pk)
168 | serializer = TeamSerializer(team, data=request.data)
169 | if serializer.is_valid():
170 | serializer.save()
171 | return Response(serializer.data)
172 | return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
173 |
174 | def delete(self, request, pk, format=None):
175 | team = self.get_object(pk)
176 | team.delete()
177 | return Response(status=status.HTTP_204_NO_CONTENT)
178 | ```
179 |
180 | W dokumentacji znajdziemy informacje o mapowaniu żądań na uprawnienia:
181 | * żądania `POST` wymagają posiadania prawa `add` na modelu,
182 | * żądania `PUT` i `PATCH` wymagają posiadania prawa `change` na modelu,
183 | * żądania `DELETE` wymagają posiadania prawa `delete` na modelu.
184 |
185 | A gdzie żądanie `GET`? Otóż chociaż mogłoby się wydawać logicznym, że powinno być mapowanie na uprawnienie `view` dla modelu, to tak nie jest. Można jednak rozszerzyć bazową klasę `DjangoModelPermissions` i dodać tę funkcjonalność.
186 |
187 | **_Listing 6_**
188 |
189 | Kod został umieszczony w pliku `permissions.py` w folderze aplikacji (nie projektu).
190 | ```python
191 | import copy
192 |
193 | from rest_framework import permissions
194 |
195 |
196 | class CustomDjangoModelPermissions(permissions.DjangoModelPermissions):
197 |
198 | def __init__(self):
199 | self.perms_map = copy.deepcopy(self.perms_map)
200 | self.perms_map['GET'] = ['%(app_label)s.view_%(model_name)s']
201 | ```
202 |
203 |
204 | ## **Zadania**
205 |
206 | **Zadanie 1**
207 | Dodaj nową grupę uprawnień w panelu administracyjnym. Dodaj do tej grupy jedno wybrane uprawnienie domyślne dla modelu, który został dodany do zarządzania w panelu administracyjnym. Stwórz nowego użytkownika, który będzie "w zespole", ale nie będzie superużytkownikiem i przypisz go do tej grupy. Zaloguj się na konto stworzonego użytkownika i sprawdź czy kontrola tego uprawnienia działa poprawnie.
208 |
209 | **Zadanie 2**
210 | Korzystając z przykładów z listingów 1 oraz 2 dodaj prosty widok, dla wyświetlania np. szczegółów danej kategorii, w logice którego sprawdź czy user posiada uprawnienie `view_category` i wyświetlaj lub nie informacje o kategorii.
211 |
212 | **Zadanie 3**
213 | Do modelu `Posts` dodaj własne uprawnienie o nazwie `can_edit_others_posts`, umożliwiające edycję postów, których dany użytkownik nie jest twórcą. Stwórz nową grupę uprawnień o nazwie `moderator forum`, przypisz do niej to uprawnienie i przestestuj na wybranym użytkowniku jego działanie.
214 |
215 | **Zadanie 4**
216 | Przetestuj działanie klasy `DjangoModelPermissions` (lub `CustomDjangoModelPermissions`) z DRF z różnymi prawami dostępu (`GET`, `PUT`, `POST`, `DELETE`). Pamiętaj, że użytkownikowi, który nie jest superuserem należy przypisać stosowne prawa do modelu (poprzez przypisanie ich do grupy).
217 |
218 |
--------------------------------------------------------------------------------
/lab_05/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## Lab 5 - Podstawowa walidacja wewnątrz serializerów danych oraz budowa pierwszych endpoint'ów REST API.
4 | ---
5 |
6 | ### **1. Walidacja danych w procesie serializacji.**
7 |
8 | #### **1.1 Walidacja na poziomie pojedynczego pola.**
9 |
10 | Oprócz automatycznej walidacji wartości pól na podstawie wybranego typu pola (numeryczne, tekstowe, daty itd.) możliwe jest również zdefiniowanie reguł walidacji, które są nieco bardziej złożone lub specyficzne dla danego problemu biznesowego. Aby automatycznie przypisać taki walidator dla konkretnego pola musimy jego nazwę zdefiniowac wg. wzorca `.validate_` wewnątrz serializera. Metoda ta przyjmuje pojedynczy argument, który jest wartością pola, które ma zostać poddane walidacji. Ta metoda zwraca zwalidowaną wartość pola lub zgłasza wyjątek `serializers.ValidationError`. Przykład poniżej.
11 |
12 | **_Listing 1_**
13 | ```python
14 | # fragment klasy PersonSerializer
15 |
16 | # walidacja wartości pola name
17 | def validate_name(self, value):
18 |
19 | if not value.istitle():
20 | raise serializers.ValidationError(
21 | "Nazwa osoby powinna rozpoczynać się wielką literą!",
22 | )
23 | return value
24 | ```
25 |
26 | Jeżeli walidacja danego pola nie powiedzie się to zmienna `.errors` przechowa stosowny komunikat o błędzie i nie pozwoli na zapisanie obiektu przed usunięciem wszystkich błędów.
27 |
28 | #### **1.2 Walidacja na poziomie obiektu.**
29 |
30 | Walidacja na poziomie obiektu jest potrzebna, kiedy niezbędne jest wykorzystanie dostępu do wielu pól. Przykład (z oficjalnej dokumentacji) poniżej.
31 |
32 | **_Listing 2_**
33 | ```python
34 | class EventSerializer(serializers.Serializer):
35 | description = serializers.CharField(max_length=100)
36 | start = serializers.DateTimeField()
37 | finish = serializers.DateTimeField()
38 |
39 | def validate(self, data):
40 | """
41 | Check that start is before finish.
42 | """
43 | if data['start'] > data['finish']:
44 | raise serializers.ValidationError("finish must occur after start")
45 | return data
46 | ```
47 |
48 | #### **1.3 Własne i wbudowane walidatory.**
49 |
50 | W przypadku gdy nasze reguły walidacji (oprócz już tych wbudowanych we frameworku) trzeba wykorzystać w wielu polach i wielu serializerach, najlepszym pomysłem jest zdefiniować je jako zewnętrzne funkcje lub obiekty. Można to zrobić wewnątrz pliku z kodem serializerów, ale jeszcze lepszym pomysłem będzie wyniesienie ich do oddzielnego modułu (pliku). Poniżej przykład dla pierwszego przypadku (również z oficjalnej dokumentacji DRF).
51 |
52 | **_Listing 3_**
53 | ```python
54 | # metoda walidująca, można stworzyć oddzielny moduł z wieloma takimi metodami
55 | # i zaimportować w różnych miejscach projektu
56 | def multiple_of_ten(value):
57 | if value % 10 != 0:
58 | raise serializers.ValidationError('Not a multiple of ten')
59 |
60 | class GameRecord(serializers.Serializer):
61 | score = IntegerField(validators=[multiple_of_ten])
62 | ...
63 | ```
64 |
65 | DRF posiada również wbudowane walidatory, które mogą służyć do walidacji np. unikalności wartości w danym zbiorze (np. w tabeli w bazie danych). Przykład jego wykorzystania poniżej.
66 |
67 | **_Listing 4_**
68 | ```python
69 | class EventSerializer(serializers.Serializer):
70 | name = serializers.CharField()
71 | room_number = serializers.IntegerField(choices=[101, 102, 103, 201])
72 | date = serializers.DateField()
73 |
74 | class Meta:
75 | # Each room only has one event per day.
76 | validators = [
77 | UniqueTogetherValidator(
78 | queryset=Event.objects.all(),
79 | fields=['room_number', 'date']
80 | )
81 | ]
82 | ```
83 |
84 | Lista oraz przykłady wykorzystania tych walidatorów znajdują się w dokumentacji pod adresem: https://www.django-rest-framework.org/api-guide/validators/
85 |
86 |
87 | ### **2. Wykorzystanie widoków APIView do tworzenia endpointów REST API.**
88 |
89 | > **Ważne: Aby skorzystać z widoków dla REST API dostarczanych z frameworkiem DRF należy w pliku `projekt\settings.py` dodać w `INSTALLED_APPS` wpis `rest_framework`.**
90 |
91 | W odróżnienu od klasy `HttpRequest` z frameworka Django, DRF wykorzystuje rozszerzającą ją klasę `Request`, która jest lepiej przystosowana do obsługi żądań REST. Wszelkie wartości takiego żądania znajdują się w zmiennej `request.data` w odróżnieniu od `request.POST` (klasa HttpRequest).
92 | Do obsługi odpowiedzi wykorzystywana jest natomiast klasa `Response`, która w podstawowej formie zawiera wszelkie dane w surowej formie i dopiero w fazie negocjacji z klientem decyduje o ich postaci.
93 |
94 | Chcąc stworzyć endpoint REST możemy wykorzystać dwa opakowania (ang. wrappers) z DRF:
95 | * dekorator `@api_view` dla widoków opartych na funkcjach,
96 | * klasę `APIView` dla widoków opartych na klasach.
97 |
98 | Poniżej przykład implementacji endpointu opartego na widokach funkcyjnych (plik `api_views.py` wewnątrz struktury danej aplikacji.)
99 |
100 | plik api_views.py (stworzony aby przechowywać endpointy oddzielnie od standardowych widowków Django)
101 | **_Listing 5_**
102 | ```python
103 | from django.shortcuts import render
104 | from rest_framework import status
105 | from rest_framework.decorators import api_view
106 | from rest_framework.response import Response
107 | from .models import Person, Team
108 | from .serializers import PersonSerializer
109 |
110 | # określamy dostępne metody żądania dla tego endpointu
111 | @api_view(['GET'])
112 | def person_list(request):
113 | """
114 | Lista wszystkich obiektów modelu Person.
115 | """
116 | if request.method == 'GET':
117 | persons = Person.objects.all()
118 | serializer = PersonSerializer(persons, many=True)
119 | return Response(serializer.data)
120 |
121 |
122 | @api_view(['GET', 'PUT', 'DELETE'])
123 | def person_detail(request, pk):
124 |
125 | """
126 | :param request: obiekt DRF Request
127 | :param pk: id obiektu Person
128 | :return: Response (with status and/or object/s data)
129 | """
130 | try:
131 | person = Person.objects.get(pk=pk)
132 | except Person.DoesNotExist:
133 | return Response(status=status.HTTP_404_NOT_FOUND)
134 |
135 | """
136 | Zwraca pojedynczy obiekt typu Person.
137 | """
138 | if request.method == 'GET':
139 | person = Person.objects.get(pk=pk)
140 | serializer = PersonSerializer(person)
141 | return Response(serializer.data)
142 |
143 | elif request.method == 'PUT':
144 | serializer = PersonSerializer(person, data=request.data)
145 | if serializer.is_valid():
146 | serializer.save()
147 | return Response(serializer.data)
148 | return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
149 |
150 | elif request.method == 'DELETE':
151 | person.delete()
152 | return Response(status=status.HTTP_204_NO_CONTENT)
153 |
154 |
155 |
156 | ```
157 |
158 | Teraz należy jeszcze w klasie serializera dodać implementację metody `update`, która jest wywoływana dla metody `PUT` dla endpointu `person_detail`.
159 | Dobre praktyki jednak mówią o tym, że powinniśmy dla każdej operacji przygotować oddzielny endpoint, co pozwoli też na lepszą granulację uprawnień w tak stworzonym systemie. Aby dodać metodę stworzenia nowego obiektu dla danego modelu możemy to zrobić dla metody `PUT` (chociaż dobre praktyki też mówią o tym, że powinien być używany do operacji UPDATE) lub lepiej przez metodę `POST`.
160 |
161 | **_Listing 6_**
162 | ```python
163 | def update(self, instance, validated_data):
164 | instance.name = validated_data.get('name', instance.name)
165 | instance.shirt_size = validated_data.get('shirt_size', instance.shirt_size)
166 | instance.data_dodanie = validated_data.get('data_dodania', instance.miesiac_dodania)
167 | instance.stanowisko = validated_data.get('stanowisko', instance.team)
168 | instance.save()
169 | return instance
170 | ```
171 |
172 | Aby całość zadziałała jak należy, niezbędne jest dodanie również odpowienich wpisów w plikach `urls.py` odpowiednich aplikacji projektu.
173 |
174 | Przykład poniżej.
175 |
176 | **_Listing 7_**
177 | ```python
178 | # plik ankiety/urls.py
179 |
180 | from django.urls import path, include
181 | from . import views
182 |
183 | urlpatterns = [
184 | path('persons/', views.person_list),
185 | # tu oczekujemy przekazania parametru typu int
186 | # który będzie w tym widoku dostępny poprzez zmienną o nazwie pk
187 | path('persons//', views.person_detail),
188 | ]
189 | ```
190 |
191 | Więcej o sposobie budowania URL-i w aplikacji Django znajdziesz w dokumentacji: https://docs.djangoproject.com/en/5.2/topics/http/urls/
192 |
193 | I przykładowy plik `projekt/urls.py` z importem url'i danej aplikacji.
194 |
195 | **_Listing 8_**
196 | ```python
197 | from django.contrib import admin
198 | from django.urls import path, include
199 |
200 |
201 | urlpatterns = [
202 | path('admin/', admin.site.urls),
203 | path('admin-tools/', include('admin_tools.urls'),),
204 | path('blog/', include('blog.urls'),)
205 | ]
206 | ```
207 |
208 | Umieszczając definicje dla każdej aplikacji wewnątrz jej struktury, uniezależniamy ją jeszcze bardziej od głównego projektu i możemy łatwiej przenosić pomiędzy projektami. Wymagane jest jeszcze dołączenie tych urli w pliku `urls.py` głównego projektu.
209 |
210 | Po poprawnej konfiguracji widok standardowy w oknie przeglądarki może wyglądać tak:
211 |
212 | 
213 |
214 |
215 | **Zadania**
216 |
217 | 1. Wykonaj zadania na nowym branchu o nazwie `feature_lab_5`. Na koniec pracy, po przetestowaniu, scal ten branch z główną gałęzią projektu.
218 | 2. Dodaj walidację pól dla klasy 'Post':
219 | * `nazwa` - może zawierać tylko litery,
220 | * `data_dodania` - nie może być z przyszłości (możliwe, że konieczne będzie zdjęcie właściwości pola tylko do odczytu).
221 | 3. Bazując na przykładach z bieżącego laboratorium przygotuj endpointy dla modeli `Category`, `Topic` i `Post`:
222 | * wyświetlanie, dodawanie i usuwanie pojedynczego obiektu typu dla każdej z powyższych encji,
223 | * wyświetlanie listy obiektów dla każdej z powyższych encji,
224 | * wyświetlenie listy obiektów typu `Category` oraz `Topic`, które zawierają w polu `name` zadany łańcuch znaków,
225 | * wyświetlanie, dodawanie i usuwanie pojedynczego obiektu typu `Category`, `Topic` oraz `Post`.
226 | 4. Korzystając z posiadanego API wykonaj:
227 | * dodaj dwa nowe obiekty `Post` eksperymentując z różnymi polami,
228 | * zmodyfikuj jeden obiekt typu `Post`,
229 | * usuń jeden obiekt typu `Post`,
230 | * wyświetl wszystkie obiekty typu `Post`, które w nazwie zawierają literę `a`.
231 | 5. Do odpytania endpointów oprócz widoków serwowanych przez DRF wykorzystaj również program `Postman` (jeżeli będzie to możliwe na komputerach w pracowni) oraz polecenie `curl` (Dokumentacja: https://curl.se/docs/manual.html).
232 | 6. Bazując na przykładzie z dokumentacji pod adresem https://www.django-rest-framework.org/tutorial/3-class-based-views/ wykonaj:
233 | * zatwierdź zmiany w poprzednim branchu,
234 | * dodaj nowy branch o nazwie `feature_lab_5_class_views` i przełącz się na niego,
235 | * zamień implementację API dla modelu `Post` zgodnie z przykładem z dokumentacji, rozszerzając klasę `APIView` DRF i przetestuj działanie,
236 | * zatwierdź zmiany na branchu, ale nie scalaj z główną gałęzią.
237 |
--------------------------------------------------------------------------------
/lab_06/readme.md:
--------------------------------------------------------------------------------
1 | # Aplikacje WWW, semestr 2025Z
2 |
3 | ## Lab 6 - Autentykacja w Django i DRF.
4 | ---
5 |
6 | ### **1. Autentykacja (uwierzytelnianie).**
7 |
8 | Autentykacja to proces polegający na potwierdzeniu tożsamości (uwierzytelnianie) klienta (aplikacji), który został wcześniej zarejestrowany w danym systemie. Autoryzacja to z kolei proces sprawdzenia uprawnień dla zasobów, do których klient próbuje uzyskać dostęp.
9 |
10 | W przypadku Django oraz DRF istnieje kilka sposobów na implementację procesu uwierzytelniania. W tym laboratorium zostaną przedstawione tylko dwie z nich: uwierzytelnianie na podstawie sesji oraz tokena.
11 |
12 | >**Oficjalna dokumentacja przydatna przy zadaniach z bieżącego labu:**
13 | >* tutorial: https://www.django-rest-framework.org/tutorial/4-authentication-and-permissions/
14 | >* Authentication API Reference: https://www.django-rest-framework.org/api-guide/authentication/
15 | >* Permissions API Reference: https://www.django-rest-framework.org/api-guide/permissions/
16 |
17 | Do tej pory dostęp do API nie jest w żaden sposób kontrolowany i każdy znając adres URL może nasze API odpytać, również dla żądań `PUT`, `POST` czy `DELETE`.
18 | Aby dla danego endpointu określić restrykcje polegającą na dostępie tylko dla zalogowanego użytkownika musimy dokonać kilku zmian w dotychczasowym projekcie.
19 |
20 | **Krok 1 - przebudowanie endpointu dla klasy Person.**
21 |
22 | Przyjmijmy, że żądanie `GET` będzie możliwe bez restrykcji, a pozostałe będą wymagały uwierzytelnionego użytkownika.
23 | Aktualnie wszystkie metody (`PUT`, `GET`, `DELETE`) są zdefiniowane w jednej funkcji, co utrudnia nam możliwość rozdzielenia uprawnień dla każdego z nich.
24 | Rozdzielimy więc oba widoki. Dla przypomnienia, poniżej oryginalny kod dla endpointów związanych z klasą Person.
25 |
26 | **_Listing 1_**
27 | ```python
28 | from django.shortcuts import render
29 | from rest_framework import status
30 | from rest_framework.decorators import api_view
31 | from rest_framework.response import Response
32 | from .models import Person, Team
33 | from .serializers import PersonSerializer
34 |
35 |
36 | @api_view(['GET'])
37 | def person_list(request):
38 | """
39 | Lista wszystkich obiektów modelu Person.
40 | """
41 | if request.method == 'GET':
42 | persons = Person.objects.all()
43 | serializer = PersonSerializer(persons, many=True)
44 | return Response(serializer.data)
45 |
46 |
47 | @api_view(['GET', 'PUT', 'DELETE'])
48 | def person_detail(request, pk):
49 |
50 | """
51 | :param request: obiekt DRF Request
52 | :param pk: id obiektu Person
53 | :return: Response (with status and/or object/s data)
54 | """
55 | try:
56 | person = Person.objects.get(pk=pk)
57 | except Person.DoesNotExist:
58 | return Response(status=status.HTTP_404_NOT_FOUND)
59 |
60 | """
61 | Zwraca pojedynczy obiekt typu Person.
62 | """
63 | if request.method == 'GET':
64 | person = Person.objects.get(pk=pk)
65 | serializer = PersonSerializer(person)
66 | return Response(serializer.data)
67 |
68 | elif request.method == 'PUT':
69 | serializer = PersonSerializer(person, data=request.data)
70 | if serializer.is_valid():
71 | serializer.save()
72 | return Response(serializer.data)
73 | return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
74 |
75 | elif request.method == 'DELETE':
76 | person.delete()
77 | return Response(status=status.HTTP_204_NO_CONTENT)
78 | ```
79 |
80 | Rozdzielamy więc metodę `GET` od reszty i dodajemy brakujące importy oraz dekoratory dla żadań `PUT` i `DELETE`.
81 |
82 | **_Listing 2_**
83 |
84 | ```python
85 | from django.shortcuts import render
86 | from rest_framework import status
87 | from rest_framework.decorators import api_view, authentication_classes, permission_classes
88 | from rest_framework.authentication import SessionAuthentication, BasicAuthentication
89 | from rest_framework.permissions import IsAuthenticated
90 | from rest_framework.response import Response
91 | from .models import Person, Team
92 | from .serializers import PersonSerializer
93 |
94 |
95 | @api_view(['GET'])
96 | def person_list(request):
97 | """
98 | Lista wszystkich obiektów modelu Person.
99 | """
100 | if request.method == 'GET':
101 | persons = Person.objects.all()
102 | serializer = PersonSerializer(persons, many=True)
103 | return Response(serializer.data)
104 |
105 |
106 | @api_view(['GET'])
107 | def person_detail(request, pk):
108 |
109 | """
110 | :param request: obiekt DRF Request
111 | :param pk: id obiektu Person
112 | :return: Response (with status and/or object/s data)
113 | """
114 | try:
115 | person = Person.objects.get(pk=pk)
116 | except Person.DoesNotExist:
117 | return Response(status=status.HTTP_404_NOT_FOUND)
118 |
119 | """
120 | Zwraca pojedynczy obiekt typu Person.
121 | """
122 | if request.method == 'GET':
123 | person = Person.objects.get(pk=pk)
124 | serializer = PersonSerializer(person)
125 | return Response(serializer.data)
126 |
127 |
128 | @api_view(['PUT', 'DELETE'])
129 | @authentication_classes([SessionAuthentication, BasicAuthentication])
130 | @permission_classes([IsAuthenticated])
131 | def person_update_delete(request, pk):
132 |
133 | """
134 | :param request: obiekt DRF Request
135 | :param pk: id obiektu Person
136 | :return: Response (with status and/or object/s data)
137 | """
138 | try:
139 | person = Person.objects.get(pk=pk)
140 | except Person.DoesNotExist:
141 | return Response(status=status.HTTP_404_NOT_FOUND)
142 |
143 | if request.method == 'PUT':
144 | serializer = PersonSerializer(person, data=request.data)
145 | if serializer.is_valid():
146 | serializer.save()
147 | return Response(serializer.data)
148 | return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
149 |
150 | elif request.method == 'DELETE':
151 | person.delete()
152 | return Response(status=status.HTTP_204_NO_CONTENT)
153 |
154 | ```
155 |
156 | Pojawienie się dekoratorów `@authentication_classes([SessionAuthentication, BasicAuthentication])` oraz `@permission_classes([IsAuthenticated])` określa odpowiednio dopuszczalne metody autentykacji oraz listę klas, które definiują wymagane uprawnienia. Bez ich spełnienia kod metody nie zostanie wykonany, a do obiektu `Response` zostanie dołączony odpowiedni kod błędu np.:
157 | ```HTTP 403 Forbidden
158 | Allow: OPTIONS, PUT, DELETE
159 | Content-Type: application/json
160 | Vary: Accept
161 |
162 | {
163 | "detail": "Nie podano danych uwierzytelniających."
164 | }
165 | ```
166 | Dodatkowo musimy również zaktualizować definicję URL-i dla zmodyfikowanych endpointów. Postać pliku `ankiety/urls.py` po modyfikacji:
167 |
168 |
169 | **_Listing 3_**
170 | ```python
171 | from django.urls import path, include
172 | from . import views
173 |
174 | urlpatterns = [
175 | path('persons/', views.person_list),
176 | path('persons//', views.person_detail),
177 | path('persons/update//', views.person_update_delete),
178 | path('persons/delete//', views.person_update_delete),
179 | ]
180 | ```
181 | Docelowo niezłym pomysłem jest budowanie oddzielnego endpointu dla każdej operacji, co zmniejszy ilość refactoringu, który będzie trzeba wykonać w przyszłości jeżeli pojawi się potrzeba dodania uprawnień dla każdego z nich z osobna.
182 |
183 | Po przetestowaniu tych dwóch endpointów powinniśmy móc wyświetlać obiekty typu Person, ale bez uwierzytelnienia nie możemy ich modyfikować ani usuwać.
184 |
185 | **Krok 2 - dodanie możliwości zalogowania się poprzez interfejs API dostarczony przez DRF.**
186 |
187 | Do pliku `urls.py` w projekcie dodajemy:
188 |
189 | **_Listing 4_**
190 | ```python
191 | urlpatterns += [
192 | path('api-auth/', include('rest_framework.urls')),
193 | ]
194 | ```
195 |
196 | Po odświeżeniu widoku DRF API pojawi się możliwość zalogowania z wykorzystaniem wcześniej utworzonych kont użytkowników. Po uwierzytelnieniu otrzymamy dostęp do wszystkich endpointów, które wymagają uprawnienia `IsAuthenticated`.
197 |
198 |
199 | **Autentykacja poprzez token**
200 |
201 | Wdrożenie prostej autentykacji poprzez token jest jednym z zadań do samodzielnego wykonania. Poniżej umieszczono kilka wskazówek, które pomogą w tym procesie i pozwolą uniknąć kilku problemów w trakcie implementacji.
202 |
203 |
204 | Autentykacja poprzez token wymaga dodania odpowiedniego atrybutu w nagłówku żądania. W zależności od klienta do odpytywania API, z którego korzystamy sam sposób przekazania może się różnić.
205 |
206 | W przypadku narzędzia `http` wiersza poleceń (Mac) może to wyglądać tak:
207 | ```bash
208 | http http://127.0.0.1:8000/hello/ 'Authorization: Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf'
209 |
210 | # lub
211 | http http://127.0.0.1:8000/hello/ 'Authorization: Bearer 9054f7aa9305e012b3c2300408c3dfdf390fcddf'
212 |
213 | ```
214 |
215 | W przypadku polecenia `curl`:
216 | ```bash
217 | curl -H "Authorization: Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf" http://127.0.0.1:8000/hello/
218 |
219 | # lub
220 |
221 | curl -H "Authorization: Bearer 9054f7aa9305e012b3c2300408c3dfdf390fcddf" http://127.0.0.1:8000/hello/
222 | ```
223 | Z poziomu czystego Pythona:
224 | ```python
225 | import requests
226 |
227 | url = 'http://127.0.0.1:8000/hello/'
228 | # poniżej też może nastąpić konieczność zamiany słowa Token na Bearer
229 | headers = {'Authorization': 'Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf'}
230 | r = requests.get(url, headers=headers)
231 | ```
232 |
233 | A w programie Postman należy przejść do zakładki `Authorization`, wybrać `Bearer Token` i podać jego wartość jak na poniższym zrzucie ekranu.
234 |
235 | 
236 |
237 | Postman narzuca też własną nazwę tokena co powoduje, że nagłówek żądania wygląda tak:
238 | ```python
239 | headers = {'Authorization': 'Bearer 9054f7aa9305e012b3c2300408c3dfdf390fcddf'}
240 | ```
241 |
242 | Można to obejść poprzez prostą własną implementację klasy `TokenAuthentication`:
243 |
244 | **_Listing_ 3**
245 | ```python
246 | class BearerTokenAuthentication(TokenAuthentication):
247 | keyword = u"Bearer"
248 | ```
249 |
250 | A następnie importujemy ją w widokach i zamieniamy nazwę `TokenAuthentication` na `BearerTokenAuthentication`. Jednak to będzie wymuszało podawanie teraz nagłówka jako `'Authorization': 'Bearer 9054f7aa9305e012b3c2300408c3dfdf390fcddf'` a nie `'Authorization': 'Token 9054f7aa9305e012b3c2300408c3dfdf390fcddf'`.
251 |
252 | Dodatkowo, dla widoków (endpointów), które będą uwierzytelniane poprzez token nie możemy używać jednocześnie kontroli uprawnienia `IsAuthenticated`.
253 |
254 | **Zadania**
255 |
256 | 1. W aplikacji rozwijanej w trakcie zajęć odtwórz opisany powyżej sposób uwierzytelniania (listing 4 i uwierzytelnianie przez wcześniej utworzone konto użytkownika Django np. superusera) i go przetestuj jeżeli nie zostało to jeszcze zrobione.
257 |
258 | 2. Zdefiniuj nowy endpoint `users/posts/`, który będzie zwracał listę wszystkich postów (model `Post` z aplikacji `blog`), ale tylko tych, które zostały utworzone przez aktualnie zalogowanego użytkownika. Dostęp do tego endpointu powinien być możliwy tylko dla uwierzytelnionych użytkowników (czyli z uprawnieniem `IsAuthenticated`). Przetestuj działanie endpointu po zalogowaniu się poprzez interfejs DRF API oraz spróbuj uzyskać dostęp bez logowania.
259 |
260 | > Wskazówka: Jeżeli dostęp do endpointu został zadeklarowany przez widok funkcyjny (a nie poprzez dziedziczenie z klasy `APIView`) to dodanie obiektu aktualnie zalogowanego usera do danych z żądania POST można zrealizować tak:
261 | ```python
262 | ...
263 | if request.method == 'POST':
264 | serializer = PersonSerializer(data=request.data)
265 | if serializer.is_valid():
266 | serializer.save(wlasciciel=request.user)
267 | return Response(serializer.data)
268 | return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
269 | ```
270 |
271 | 3. Korzystając z dokumentacji zawartej w https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication dodaj obsługę tokenów w aplikacji. Dodaj również tokeny dla istniejących userów. Zauważ, że jest to prosty mechanizm tokenów dla aplikacji Django. Jeżeli chcesz skorzystać z bardziej zaawansowanego mechanizmu (np. JWT) to musisz użyć dodatkowej biblioteki (np. `djangorestframework-simplejwt`) do czego zachęcam.
272 |
273 | 4. Rozbij endpoint dla `Post` na oddzielne endpointy dla żądania typu `PUT` oraz `DELETE` i dla tego drugiego ustaw autentykację poprzez token. Przetestuj działanie za pomocą narzędzia `curl` lub `Postman`.
274 |
275 | 5. Dodaj lub zmodyfikuj istniejący endpoint tak aby możliwe było wyświetlenie wszystkich obiektów typu `Topic` dla podanej kategorii. Niech url dla niego będzie postaci `.\categories\\topics\`. Niech dostęp będzie tylko do odczytu i tylko poprzez autoryzację tokenem.
--------------------------------------------------------------------------------