Как использовать сессии

Django полностью поддерживает анонимные сессии. Фреймворк сессий позволяет хранить и извлекать произвольные данные для каждого посетителя сайта. Данные хранятся на стороне сервера, а отправка и получение куки-файлов абстрагированы. Куки-файлы содержат идентификатор сессии, а не сами данные (если вы не используете хранилище сессий на основе куки).

Включение сессий

Сессии реализуются с помощью модуля middleware.

Для включения функциональности сессий выполните следующие действия:

• Отредактируйте настройку MIDDLEWARE и убедитесь, что она содержит 'django.contrib.sessions.middleware.SessionMiddleware'. По умолчанию settings.py созданная django-admin startproject имеет SessionMiddleware включёнными.

Если вы не хотите использовать сессии, можете удалить строку SessionMiddleware из MIDDLEWARE и 'django.contrib.sessions' из INSTALLED_APPS. Это сэкономит немного ресурсов.

Настройка движка сессий

По умолчанию Django хранит сессии в базе данных (используя модель django.contrib.sessions.models.Session). Хотя это удобно, в некоторых случаях быстрее хранить данные сессии в другом месте, поэтому Django можно настроить на хранение данных сессий на файловой системе или в кэше.

Использование сессий, поддерживаемых базой данных

Если вы хотите использовать сессии, поддерживаемые базой данных, необходимо добавить 'django.contrib.sessions' в настройку INSTALLED_APPS.

После настройки вашей установки запустите manage.py migrate для создания единственной таблицы базы данных, которая хранит данные сессии.

Использование кэшированных сессий

Для повышения производительности вы можете использовать хранилище сессий на основе кэша.

Чтобы хранить данные сессий с помощью системы кэширования Django, сначала необходимо настроить свой кэш; см. документацию по кэшированию для получения подробной информации.

Если в CACHES определено несколько кэшей, Django будет использовать кэш по умолчанию. Чтобы использовать другой кэш, установите SESSION_CACHE_ALIAS на имя этого кэша.

После настройки кэша у вас есть два варианта хранения данных в кэше:

• Установите SESSION_ENGINE на "django.contrib.sessions.backends.cache" для простого хранилища кэшированных сессий. Данные сессий будут храниться непосредственно в вашем кэше. Однако данные сессии могут не сохраняться: данные кэша могут быть удалены, если кэш заполнится или если сервер кэша перезапустится.
• Для сохранения данных кэша, установите SESSION_ENGINE на "django.contrib.sessions.backends.cached_db". Это использует кэш с прохождением записи — каждая запись в кэш также будет записываться в базу данных. Чтение сессий использует только базу данных, если данные уже не находятся в кэше.

Оба хранилища сессий достаточно быстры, но простое хранилище кэша быстрее, поскольку оно игнорирует сохранение. В большинстве случаев хранилище cached_db будет достаточно быстрым, но если вам нужна максимальная производительность и вы готовы время от времени удалять данные сессии, хранилище cache для вас.

Если вы используете хранилище сессий cached_db, вам также необходимо следовать инструкциям по настройке для использования сессий, поддерживаемых базой данных.

Использование файловых сессий

Чтобы использовать файловые сессии, установите настройку SESSION_ENGINE на "django.contrib.sessions.backends.file".

Также вы можете установить настройку SESSION_FILE_PATH (по умолчанию значение берется из tempfile.gettempdir(), скорее всего /tmp), чтобы управлять тем, где Django хранит файлы сессий. Убедитесь, что ваш веб-сервер имеет разрешения на чтение и запись в этом месте.

Использование сессий на основе куки

Чтобы использовать сессии на основе куки, установите настройку SESSION_ENGINE на "django.contrib.sessions.backends.signed_cookies". Данные сессии будут храниться с помощью инструментов Django для криптографического подписания и настройки SECRET_KEY.

Использование сессий в представлениях

Когда SessionMiddleware активировано, каждый объект HttpRequest — первый аргумент любой функции представления Django — будет иметь атрибут session, который представляет собой объект типа словарь.

Вы можете читать и записывать в request.session в любой момент в вашем представлении. Вы можете редактировать его несколько раз.

class backends.base.SessionBase

Это базовый класс для всех объектов сессии. Он имеет следующие стандартные методы словаря:

__getitem__(key)

Пример: fav_color = request.session['fav_color']

__setitem__(key, value)

Пример: request.session['fav_color'] = 'blue'

__delitem__(key)

Пример: del request.session['fav_color']. Это вызывает KeyError если указанный key ещё не находится в сессии.

__contains__(key)

Пример: 'fav_color' in request.session

get(key, default=None)

Пример: fav_color = request.session.get('fav_color', 'red')

pop(key, default=__not_given)

Пример: fav_color = request.session.pop('fav_color', 'blue')

keys()

items()

setdefault()

clear()

Также у него есть эти методы:

flush()

Удаляет текущие данные сессии из сессии и удаляет cookie сессии. Это используется, если вы хотите гарантировать, что к предыдущим данным сессии больше нельзя получить доступ из браузера пользователя (например, функция django.contrib.auth.logout() вызывает её).

set_test_cookie()

Устанавливает тестовое cookie для определения, поддерживает ли браузер пользователя cookie. Из-за того, как работают cookie, вы сможете протестировать это только при следующем запросе страницы пользователя. Дополнительную информацию см. в разделе «Установка тестовых cookie» ниже.

test_cookie_worked()

Возвращает либо True или False, в зависимости от того, принял ли браузер пользователя тестовое cookie. Из-за того, как работают cookie, вам нужно будет вызвать set_test_cookie() в предыдущем отдельном запросе страницы. Дополнительную информацию см. в разделе «Установка тестовых cookie» ниже.

delete_test_cookie()

Удаляет тестовое cookie. Используйте это, чтобы очистить за собой.

set_expiry(value)

Устанавливает время истечения срока действия сессии. Вы можете передать различные значения:

• Если value является целым числом, сессия истечёт через указанное количество секунд бездействия. Например, вызов request.session.set_expiry(300) приведет к истечению сессии через 5 минут.
• Если value является объектом datetime или timedelta, сессия истечёт в указанную дату/время. Обратите внимание, что значения datetime и timedelta сериализуются только при использовании PickleSerializer.
• Если value равно 0, cookie сессии пользователя истечёт при закрытии веб-браузера пользователя.
• Если value равно None, сессия вернётся к использованию глобальной политики истечения срока действия сессии.

Чтение сессии не считается активностью для целей истечения срока действия. Истечение срока действия сессии вычисляется на основе последнего времени изменения сессии.

get_expiry_age()

Возвращает количество секунд до истечения срока действия этой сессии. Для сессий без пользовательской настройки срока действия (или тех, которые должны истекать при закрытии браузера), это будет равно SESSION_COOKIE_AGE.

Эта функция принимает два необязательных ключевых аргумента:

• modification: последнее изменение сессии в виде объекта datetime. По умолчанию — текущее время.
• expiry: информация об истечении срока действия сессии в виде объекта datetime, целого числа (в секундах) или None. По умолчанию — значение, сохранённое в сессии функцией set_expiry(), если оно есть, или None.

get_expiry_date()

Возвращает дату истечения срока действия этой сессии. Для сессий без пользовательской настройки срока действия (или тех, которые должны истекать при закрытии браузера), это будет дата через SESSION_COOKIE_AGE секунд от текущей.

Эта функция принимает те же ключевые аргументы, что и get_expiry_age().

get_expire_at_browser_close()

Возвращает либо True или False, в зависимости от того, истечёт ли cookie сессии пользователя при закрытии веб-браузера пользователя.

clear_expired()

Удаляет истекшие сессии из хранилища сессий. Этот метод класса вызывается clearsessions.

cycle_key()

Создаёт новый ключ сессии, сохраняя при этом текущие данные сессии. django.contrib.auth.login() вызывает этот метод, чтобы смягчить проблему фиксации сессий.

Сериализация сессий

По умолчанию Django сериализует данные сессии с помощью JSON. Вы можете настроить формат сериализации сессии, используя параметр SESSION_SERIALIZER. Даже с оговорками, описанными в Написание собственного сериализатора, мы настоятельно рекомендуем придерживаться сериализации JSON, особенно если вы используете хранилище cookie.

Например, вот сценарий атаки, если вы используете pickle для сериализации данных сессии. Если вы используете хранилище сессии с подписью cookie и SECRET_KEY известен атакующему (нет внутренней уязвимости в Django, которая бы привела к утечке), атакующий может вставить строку в свою сессию, которая при распаковке выполнит произвольный код на сервере. Техника для этого проста и легко доступна в интернете. Хотя хранилище сессии с cookie подписывает данные, сохранённые в cookie, для предотвращения подделки, утечка SECRET_KEY сразу же приводит к уязвимости удалённого выполнения кода.

Встроенные сериализаторы

class serializers.JSONSerializer

Обёртка над JSON-сериализатором из django.core.signing. Может сериализовать только базовые типы данных.

Кроме того, поскольку JSON поддерживает только строковые ключи, обратите внимание, что использование нестроковых ключей в request.session не будет работать должным образом:

>>> # initial assignment
>>> request.session[0] = 'bar'
>>> # subsequent requests following serialization & deserialization
>>> # of session data
>>> request.session[0]  # KeyError
>>> request.session['0']
'bar'

Аналогично, данные, которые нельзя закодировать в JSON, такие как не-UTF8 байты, например, '\xd9' (что вызывает UnicodeDecodeError), нельзя хранить.

См. раздел Написание собственного сериализатора для получения дополнительной информации об ограничениях сериализации JSON.

class serializers.PickleSerializer

Поддерживает произвольные объекты Python, но, как описано выше, может привести к уязвимости удалённого выполнения кода, если SECRET_KEY станет известен злоумышленнику.

Написание собственного сериализатора

Обратите внимание, что в отличие от PickleSerializer, JSONSerializer не может обрабатывать произвольные типы данных Python. Как часто бывает, существует компромисс между удобством и безопасностью. Если вы хотите хранить более сложные типы данных, включая datetime и Decimal в сессиях на основе JSON, вам потребуется написать пользовательский сериализатор (или преобразовать такие значения в сериализуемый в JSON объект перед их хранением в request.session). Хотя сериализация этих значений довольно проста (DjangoJSONEncoder может быть полезен), написание декодера, который надежно восстановит то же самое, что вы ввели, более хрупкое. Например, вы рискуете вернуть datetime, который на самом деле был строкой, которая просто оказалась в том же формате, который был выбран для datetime.

Класс вашего сериализатора должен реализовывать два метода, dumps(self, obj) и loads(self, data), для сериализации и десериализации словаря данных сессии соответственно.

Рекомендации по объектам сессии

• Используйте обычные строки Python в качестве ключей словаря в request.session. Это больше соглашение, чем жёсткое правило.
• Ключи словаря сессии, начинающиеся с символа подчеркивания, зарезервированы для внутреннего использования Django.
• Не перезаписывайте request.session новым объектом и не обращайтесь к его атрибутам или не устанавливайте их. Используйте его как словарь Python.

Примеры

Этот упрощенный вид устанавливает переменную has_commented в значение True после того, как пользователь отправил комментарий. Он не позволяет пользователю отправлять комментарий более одного раза:

def post_comment(request, new_comment):
    if request.session.get('has_commented', False):
        return HttpResponse("You've already commented.")
    c = comments.Comment(comment=new_comment)
    c.save()
    request.session['has_commented'] = True
    return HttpResponse('Thanks for your comment!')

Этот упрощенный вид выполняет вход «члена» сайта:

def login(request):
    m = Member.objects.get(username=request.POST['username'])
    if m.password == request.POST['password']:
        request.session['member_id'] = m.id
        return HttpResponse("You're logged in.")
    else:
        return HttpResponse("Your username and password didn't match.")

…А этот вид выполняет выход члена, согласно login() выше:

def logout(request):
    try:
        del request.session['member_id']
    except KeyError:
        pass
    return HttpResponse("You're logged out.")

Стандартная функция django.contrib.auth.logout() фактически делает немного больше, чем это, чтобы предотвратить непреднамеренную утечку данных. Она вызывает метод flush() объекта request.session. Мы используем этот пример для демонстрации работы с объектами сессии, а не для полного logout() реализации.

Установка тестовых файлов cookie

Для удобства Django предоставляет простой способ проверки, принимает ли браузер пользователя файлы cookie. Просто вызовите метод set_test_cookie() объекта request.session в представлении и вызовите test_cookie_worked() в последующем представлении – не в том же вызове представления.

Эта неловкая разборка между set_test_cookie() и test_cookie_worked() необходима из-за работы файлов cookie. Когда вы устанавливаете файл cookie, вы не можете точно сказать, принял ли его браузер, пока браузер не сделает следующий запрос.

Хорошей практикой является использование delete_test_cookie(), чтобы очистить за собой. Сделайте это после того, как вы подтвердили, что тестовый файл cookie сработал.

Вот типичный пример использования:

from django.http import HttpResponse
from django.shortcuts import render

def login(request):
    if request.method == 'POST':
        if request.session.test_cookie_worked():
            request.session.delete_test_cookie()
            return HttpResponse("You're logged in.")
        else:
            return HttpResponse("Please enable cookies and try again.")
    request.session.set_test_cookie()
    return render(request, 'foo/login_form.html')

Использование сессий вне представлений

>>> from importlib import import_module
>>> from django.conf import settings
>>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore

Доступен API для управления данными сессии вне представления:

>>> from django.contrib.sessions.backends.db import SessionStore
>>> s = SessionStore()
>>> # stored as seconds since epoch since datetimes are not serializable in JSON.
>>> s['last_login'] = 1376587691
>>> s.create()
>>> s.session_key
'2b1189a188b44ad18c35e113ac6ceead'
>>> s = SessionStore(session_key='2b1189a188b44ad18c35e113ac6ceead')
>>> s['last_login']
1376587691

SessionStore.create() предназначен для создания новой сессии (т. е. сессии, которая не загружена из хранилища сессий и у которой session_key=None). save() предназначен для сохранения существующей сессии (т. е. сессии, загруженной из хранилища сессий). Вызов save() для новой сессии также может сработать, но существует небольшой шанс, что будет сгенерирован session_key, который конфликтует с существующей. create() вызывает save() и циклически ищет до тех пор, пока не будет сгенерирована неиспользуемая session_key.

Если вы используете бэкэнд django.contrib.sessions.backends.db, каждая сессия – просто обычная модель Django. Модель Session определена в django/contrib/sessions/models.py. Поскольку это обычная модель, вы можете получать доступ к сессиям, используя обычный API базы данных Django:

>>> from django.contrib.sessions.models import Session
>>> s = Session.objects.get(pk='2b1189a188b44ad18c35e113ac6ceead')
>>> s.expire_date
datetime.datetime(2005, 8, 20, 13, 35, 12)

Обратите внимание, что вам необходимо вызвать get_decoded(), чтобы получить словарь сессии. Это необходимо, потому что словарь хранится в закодированном формате:

>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}

Когда сессии сохраняются

По умолчанию Django сохраняет данные в базе данных сессии только тогда, когда сессия была изменена – то есть, если какие-либо значения словаря были назначены или удалены:

# Session is modified.
request.session['foo'] = 'bar'

# Session is modified.
del request.session['foo']

# Session is modified.
request.session['foo'] = {}

# Gotcha: Session is NOT modified, because this alters
# request.session['foo'] instead of request.session.
request.session['foo']['bar'] = 'baz'

В последнем случае из приведенного выше примера мы можем явно указать объекту сессии, что он был изменен, установив атрибут modified в объекте сессии:

request.session.modified = True

Чтобы изменить это поведение по умолчанию, установите параметр SESSION_SAVE_EVERY_REQUEST в значение True. Если он установлен в значение True, Django будет сохранять сессию в базе данных на каждом запросе.

Обратите внимание, что файл cookie сессии отправляется только при создании или изменении сессии. Если SESSION_SAVE_EVERY_REQUEST имеет значение True, файл cookie сессии будет отправляться на каждом запросе.

Аналогично, часть expires файла cookie сессии обновляется каждый раз, когда отправляется файл cookie сессии.

Сессия не сохраняется, если код состояния ответа – 500.

Сессии на время работы браузера и постоянные сессии

Вы можете управлять использованием сессий на время работы браузера или постоянных сессий с помощью параметра SESSION_EXPIRE_AT_BROWSER_CLOSE.

По умолчанию SESSION_EXPIRE_AT_BROWSER_CLOSE установлен в значение False, что означает, что файлы cookie сессии будут храниться в браузерах пользователей до тех пор, пока не истечёт срок действия SESSION_COOKIE_AGE. Используйте это, если не хотите, чтобы пользователи каждый раз при открытии браузера проходили вход.

Если SESSION_EXPIRE_AT_BROWSER_CLOSE установлен на значение True, Django будет использовать файлы cookie с длительностью работы браузера – файлы cookie, которые истекают сразу после того, как пользователь закроет браузер. Используйте это, если вы хотите, чтобы пользователи каждый раз при открытии браузера проходили вход.

Этот параметр является глобальным значением по умолчанию и может быть перезаписан на уровне отдельной сессии, вызывая метод set_expiry() объекта request.session, как описано выше в разделе использование сессий в представлениях.

Очистка хранилища сессий

По мере создания новых сессий на вашем веб-сайте данные сессий могут накапливаться в хранилище сессий. Если вы используете бэкэнд базы данных, таблица базы данных django_session будет расти. Если вы используете файловый бэкэнд, ваш временный каталог будет содержать всё большее количество файлов.

Чтобы понять эту проблему, рассмотрим, что происходит с бэкэндом базы данных. Когда пользователь входит в систему, Django добавляет строку в таблицу базы данных django_session. Django обновляет эту строку каждый раз, когда изменяются данные сессии. Если пользователь выходит из системы вручную, Django удаляет строку. Но если пользователь не выходит из системы, строка никогда не удаляется. Аналогичный процесс происходит с файловым бэкэндом.

Django не предоставляет автоматического удаления устаревших сессий. Поэтому вам нужно регулярно удалять устаревшие сессии. Для этой цели Django предоставляет команду управления очистки: clearsessions. Рекомендуется вызывать эту команду регулярно, например, как ежедневную задачу cron.

Обратите внимание, что бэкэнд кэша не подвержен этой проблеме, потому что кэши автоматически удаляют устаревшие данные. Также не подвержен проблеме бэкэнд файлов cookie, поскольку данные сессии хранятся в браузерах пользователей.

Настройки

Несколько настроек Django дают вам контроль над поведением сессий:

• SESSION_CACHE_ALIAS
• SESSION_COOKIE_AGE
• SESSION_COOKIE_DOMAIN
• SESSION_COOKIE_HTTPONLY
• SESSION_COOKIE_NAME
• SESSION_COOKIE_PATH
• SESSION_COOKIE_SECURE
• SESSION_ENGINE
• SESSION_EXPIRE_AT_BROWSER_CLOSE
• SESSION_FILE_PATH
• SESSION_SAVE_EVERY_REQUEST
• SESSION_SERIALIZER

Безопасность сессий

Поддомены на сайте могут устанавливать cookie на клиенте для всего домена. Это делает возможным фиксацию сессии, если cookie разрешены от поддоменов, не контролируемых надёжными пользователями.

Например, злоумышленник может войти на good.example.com и получить действительную сессию для своей учётной записи. Если злоумышленник контролирует bad.example.com, он может использовать его для отправки своего ключа сессии, так как поддомен разрешён для установки cookie на *.example.com. Когда вы посещаете good.example.com, вы войдёте как злоумышленник и, возможно, ненамеренно введёте свои конфиденциальные данные (например, данные кредитной карты) в учётную запись злоумышленника.

Ещё одна возможная атака произойдёт, если good.example.com установит свой SESSION_COOKIE_DOMAIN на ".example.com", что приведёт к отправке cookie сессии с этого сайта на bad.example.com.

Технические детали

• Словарь сессии принимает любой json сериализуемый объект при использовании JSONSerializer или любой пиклируемый Python-объект при использовании PickleSerializer. Для получения дополнительной информации обратитесь к модулю pickle.
• Данные сессии хранятся в таблице базы данных под названием django_session.
• Django отправляет cookie только в случае необходимости. Если вы не установили никаких данных сессии, cookie сессии не будет отправлено.

Объект SessionStore

При внутренней работе с сессиями Django использует объект хранилища сессии из соответствующего движка сессий. По соглашению, класс объекта хранилища сессии называется SessionStore и расположен в модуле, указанном в SESSION_ENGINE.

Все классы SessionStore доступные в Django наследуются от SessionBase и реализуют методы обработки данных, а именно:

• exists()
• create()
• save()
• delete()
• load()
• clear_expired()

Для создания собственного движка сессий или для настройки существующего можно создать новый класс, наследующийся от SessionBase или любого другого существующего класса SessionStore.

Расширение большинства движков сессий довольно просто, но для расширения движков сессий на базе БД обычно требуется дополнительная работа (подробности см. в следующем разделе).

Расширение движков сессий на базе БД

Создание настраиваемого движка сессий на базе БД, построенного на основе тех, что включены в Django (а именно db и cached_db), может быть выполнено путём наследования AbstractBaseSession и класса SessionStore.

AbstractBaseSession и BaseSessionManager импортируются из django.contrib.sessions.base_session, чтобы их можно было импортировать без включения django.contrib.sessions в INSTALLED_APPS.

class base_session.AbstractBaseSession

Новое в Django 1.9.

Абстрактная базовая модель сессии.

session_key

Первичный ключ. Само поле может содержать до 40 символов. Текущая реализация генерирует строку из 32 символов (случайная последовательность цифр и строчных букв ASCII).

session_data

Строка, содержащая закодированный и сериализованный словарь сессии.

expire_date

Дата и время истечения срока действия сессии.

Истекшие сессии недоступны пользователю, однако они всё ещё могут храниться в базе данных до тех пор, пока не выполнится команда управления clearsessions.

classmethod get_session_store_class()

Возвращает класс хранилища сессии, который будет использоваться с этой моделью сессии.

get_decoded()

Возвращает раскодированные данные сессии.

Декодирование выполняется классом хранилища сессии.

Также вы можете настроить менеджер модели, унаследовав от BaseSessionManager:

class base_session.BaseSessionManager

Новое в Django 1.9.

encode(session_dict)

Возвращает заданный словарь сессии, сериализованный и закодированный как строка.

Кодирование выполняется классом хранилища сессии, связанным с классом модели.

save(session_key, session_dict, expire_date)

Сохраняет данные сессии для заданного ключа сессии или удаляет сессию, если данные пустые.

Настройка классов SessionStore выполняется путём переопределения методов и свойств, описанных ниже:

class backends.db.SessionStore

Реализует хранилище сессий на базе БД.

classmethod get_model_class()

Новое в Django 1.9.

Переопределите этот метод, чтобы вернуть пользовательскую модель сессии, если это необходимо.

create_model_instance(data)

Новое в Django 1.9.

Возвращает новый экземпляр объекта модели сессии, представляющий текущее состояние сессии.

Переопределение этого метода предоставляет возможность модифицировать данные модели сессии перед сохранением в базе данных.

class backends.cached_db.SessionStore

Реализует кэшированное хранилище сессий на базе БД.

cache_key_prefix

Новое в Django 1.9.

Префикс, добавляемый к ключу сессии для создания строки ключа кэша.

Пример

Пример ниже демонстрирует пользовательский движок сессий на базе БД, включающий дополнительный столбец базы данных для хранения идентификатора учётной записи (предоставляя возможность запросить в базе данных все активные сессии для учётной записи):

from django.contrib.sessions.backends.db import SessionStore as DBStore
from django.contrib.sessions.base_session import AbstractBaseSession
from django.db import models

class CustomSession(AbstractBaseSession):
    account_id = models.IntegerField(null=True, db_index=True)

    @classmethod
    def get_session_store_class(cls):
        return SessionStore

class SessionStore(DBStore):
    @classmethod
    def get_model_class(cls):
        return CustomSession

    def create_model_instance(self, data):
        obj = super(SessionStore, self).create_model_instance(data)
        try:
            account_id = int(data.get('_auth_user_id'))
        except (ValueError, TypeError):
            account_id = None
        obj.account_id = account_id
        return obj

Если вы мигрируете от встроенного движка сессий Django к пользовательскому на основе cached_db, вы должны переопределить префикс ключа кэша, чтобы предотвратить конфликт имён:

class SessionStore(CachedDBStore):
    cache_key_prefix = 'mysessions.custom_cached_db_backend'

    # ...

Идентификаторы сессий в URL-адресах

Фреймворк Django для сессий полностью и исключительно основан на cookie. Он не использует URL-адреса для идентификаторов сессий в качестве крайнего решения, как PHP. Это преднамеренное конструкторское решение. Такое поведение не только делает URL-адреса некрасивыми, но и делает ваш сайт уязвимым к краже идентификаторов сессий через заголовок «Referer».