Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Spidola, Вы писали:
S>>Верхний урл всегда один и тот же. Есди у вас требуется обеспечивать пользователю возможность прямых ссылок на конкретные страницы, то это проблематично.
S>Именно. Публичный сервис.
S>> Для нас это плюс, поскольку во внутренний контур безопасности системы (другими словами, на любую страницу), можно попасть только после авторизации через конкретную страницу и организацию сессии на сервере...
S>Это тоже косяк. Нормальные системы авторизации построены не на незнании прямого урла. При попытке им проследовать просто сначала предъявляется логин-форма, но потом юзер таки попадает в ту страницу, куда шел.
Так прямого урла никто не знает, во-первых, во-вторых заход через кривой урл в принципе невозможен, даже случайно, а в третьих все урлы кроме первого входного криптуются... Попадать на нужную страницу нет необходимости (опять таки в нашей системе), поскольку есть несколько бизнес-процессов, подразумевающих выполнение некоторого набора операций и и имеющие конкретную точку входа на процесс, привязанную к меню. Таким образом, человек по любомцу должен попадать сначала на авторизацию, потом на "распределитель".
Т.е. другими словами, информация в нашей системе не существует независимо от контекста её испрользования, поэтому переход сразу на конкретную страницу не предполагается.
С другой стороны, например, существует набор вебсервисов, которые позволяют выцепить такую информацию извне (например, какую-то конкретную картинку). Эти сервисы подразумевают передачу авторизационной информации непосредственно в ХML-запросе, к примеру. Это позволяет давать уже оторванную от контекста информацию наружу. Т.е. получается, что есть "защитный периметр" системы, который можно пересечь либо через форму авторизации, либо через механизм авторизации внутри вебсервиса, но в последнем случае внешняя система имеет доступ к ограниченному функционалу.
Ой, чего-то я увлёкся...
S>>Поисковик сквозь авторизацию всё-равно не пройдёт, поэтому не проиндексирует внутренности сайта, а пользователь (даже поимев ссылку на страницу внутренего фрэйма), будет попадать на страницу авторизации.
S>У нас все наоборот. Надо не затруднять пользование сайтом, в том числе и индексацию и печать, а наоборот упрощать.
Ну раз задача обратная, то и технологию надо наизнанку выворачивать, отчего решение со статической, а не с динамической, информацией во фрэймах вполне подходит
S>>Печать страницы делать сложнее, поскольку содержимое iframe печатается как видится, т.е. в окне с казанными размерами iframe-а. Что влезло, то напечаталось — остальное за кадром. Приходится делать специальную кнопку, которая бы открывала, к примеру, ещё одно окно и всё содержимое прорисовывала бы уже одним лопухом без внутреннего фрэйма...
S>>Что касается скорости, то фактически нарисовав внешний "фрэймворк" в виде страницы и загрузив единожды туда всё, что можно, дальше в процессе работы пользователя грузятся только непосредственно необходимые данные и управляющие контролы.
S>Это-то то понятно. Я и пытаюсь вывернуть вашу схему наизнанку, чтобы сохранить преимущества скорости, избавившись от проблем с навигацией/индексацией/печатью.
См.Выше
Это как обычно — либо шашечки, либо ехать...
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Здравствуйте, Sinclair, Вы писали:
Ещё одно замечание насчёт использование фрэймов и т.п. Касается особенностей поисковых машин. То, что на странице и то, что фо фрэйме поисковиками будет рассматриваться как разные страницы, как минимум... И, желательно, перед использованием фрэймов почитать рекомендации тех поисковиков и каталогизаторов, которые вы предполагаете задействовать...
Например, почитать документы типа
такого... << RSDN@Home 1.1.4 beta 7 rev. 447>>
