Сожалеем, но текст оригинала доступен только зарегистрированным пользователям. |
До сих пор ваше приложение, по существу, было однопользовательским. Хотя ваши APEX приложения создавались с возможностью поддержки многих пользователей (а лежащая в основе база данных Oracle данных может поддерживать сотни пользователей одновременно), однако вы не пользовались этими возможностями. В последней главе второго раздела этой книги, вы изучите, как создавать пользователей и обеспечивать безопасность вашего приложения. Как и в других главах, полученные знания дадут вам возможность разрабатывать и применять надежные функции безопасности в ваших приложениях.
neutrino150
14.06.12 в 12:38
|
|
Основы безопасности. Прежде чем приступить к реализации защиты APEX приложений, вам придется понять некоторые основы безопасности приложений APEX.
neutrino150
15.06.12 в 08:27
|
|
Аутентификация. Аутентификация - это процесс установления личности пользователя. Вы, наверное, имеете дело с аутентификацией каждый день,начиная от входа в сеть и до использования персонализированных веб-сайтов. Как правило, аутентификация осуществляется с помощью уникального сочетания имени пользователя и пароля. APEX приложения используют именно этот подход.Точный метод который используется для создания и ссылки на пользователей осуществляется с помощью схем авторизации.
neutrino150
15.06.12 в 08:31
|
|
Схемы аутентификации. Все APEX приложения используют схемы аутентификации. Схема аутентификации описывает методы которые APEX использует для проверки имени пользователя и пароля. Приложение может иметь более одной схемы аутентификации, но только одна схема может быть текущей. Open Door Credentials: разрешает любой доступ к приложению. Приложение по-прежнему использует для входа страницу имя пользователя, но пароль не требуется. Эта схема особенно полезна при разработке приложений когда вы хотите проверить доступ без использования реального пользователя.
Application Express Account Credentials: Вы можете создавать пользователей и управлять ими в среде APEX. Эта схема дает вам полный контроль над пользователями и проверкой их подлинности, но остается независимой от любых других схем авторизации, которые уже существуют в вашей среде.
Database Account Credentials: Используются существующие аккаунты пользователей Oracle для авторизации.Так как APEX построен на базе данных Oracle, многие пользователи уже имеют учетные записи Oracle и они хотели бы их использовать повторно.
LDAP Credentials: используется LDAP сервер для аутентификации пользователей.
Есть несколько других предварительно настроенных схем аутентификации, что позволяет вам интегрировать другие Oracle технологии как часть общего процесса аутентификации. Кроме того, вы можете определить свои собственные схемы аутентификации, используя PL / SQL функцию, которыая возвращает логическое значение (TRUE или FALSE), что позволяет управлять доступом к приложениям и их компонентам. APEX предоставляет свою собственную проверку подлинности, это обсудим в конце главы. И тем не менее, в APEX можно использовать внешние методы аутентификации. Пожалуйста, обратитесь на форум APEX в Oracle Technology Network (OTN) для получения дополнительной информации по работе с этими методами. Наконец, вы можете выбрать вариант без аутентификации , что сделает приложение общедоступным.
neutrino150
15.06.12 в 08:45
|
|
Как это работает. Приложение, которое вы создали включает в себя набор схем авторизации реализованных по умолчанию, в том числе и схема APEX Account Credentials, которая является текущей для вашего приложения и которую вы будете использовать в этой главе. Вы можете посмотреть доступные схемы аутентификации приложения. 1. Перейдите на вкладку Application Builder в среде разработки, а затем нажмите на Shared Components.
2. В разделе Security на этой странице, нажмите на Authentication Schemes, чтобы открыть страницу как показано на рисунке 9-1. Вы можете видеть, что существуют три схемы для данного приложения: схема аутентификации APEX account credentials, которая используется в данный момент, далее схема DATABASE ACCOUNT, которая использует предварительно настроенную схема такого же типа, и наконец схема DATABASE, которая берет имя пользователя из Data Access Descriptor (DAD) целевой базы данных Oracle. Для целей настоящей главы и упражнений, продолжим использовать APEX схемы авторизации. Следующий шаг в изучении аутентификации - это создание пользователей, которые будут иметь различные уровни доступа к вашему приложению.
neutrino150
15.06.12 в 09:52
|
|
Техническая заметка - Безопасность есть всегда.
Если аутентификация включена, то APEX приложение будет знать, кто входит в систему до того как пользователь получит доступ к компонентам приложения. Если личность пользователя не установлена (во время сеанса), APEX использует страницу входа для запроса имени пользователя и пароля, когда кто-то пытается получить доступ к странице. Вы были свидетелями этого явления, когда возвращались, чтобы снова запустить страницу приложения после того, как уходили с нее на некоторое время. Когда вы запускаете страницу, вы должны сначала аутентифицироваться, прежде чем попасть на выбранную страницу.
neutrino150
18.07.12 в 10:08
|
|
Создаем пользователей.
Когда вы используете аутентификационную схему APEX account credentials (регистрационных данных аккаунта АРЕХ), вы можете задавать пользователей внутри среды АРЕХ. В упражнениях этой главы, созданных для демонстрации некоторых методов управления безопасностью, вам нужно будет задать четырех пользователей: администратора, менеждера, представителя по продажам, работающего на менеджера и обычного пользователя.
Miblocko
09.07.12 в 18:55
|
|
Попробуйте создать пользователей. Создание пользователей осуществляется в администранивной утилите среды разработки APEX. 1. В среде разработки приложений щелкните вкладку Utilities. 2. В списке Tasks в правой части страницы, щелкните ссылку, вы окажетесь на странице, изображенной на рис. 9-2.
Naias
11.07.12 в 08:59
|
|
3. Нажмите на стрелку в правой части значка Manage Application Express Users, появиться выбор: Users or User Groups. Уже по названию можно судить что, пункт User Groups позволяет объединить нескольких пользователей в одну сущность для более легкого управления безопасностью большого числа пользователей. Вам не нужно использовать для группы в рамках настоящей книги. 4. Выберите Users и затем меню Manage Existing Users, чтобы открыть страницу, показанную на рисунке 9-3. Ах, какой милый маленький значок! Каждый из этих маленьких значков представляет пользователя. Прямо сейчас, вы можете видеть своего пользователя, который окрашен в красный цвет. Цвета указывают на уровни привилегий для среды APEX, как вы увидите на следующей странице. В небольшом проекте, вы, вероятно, будет как администратор так и разработчик. Когда одно рабочее пространство используется для нескольких приложений, то там больше шансов что некоторые люди будут в роли разработчиков, но без привилегий администратора рабочего пространства. 5. Нажмите на кнопку Create, чтобы открыть страницу, показанную на рисунке 9-4.
neutrino150
15.08.12 в 09:22
|
|
На этой странице вы можете внести ключевую информацию о выбранном пользователе Apex. 6. Введите ADMIN в качестве имени пользователя и легко запоминающийся пароль длинною не менее шести символов. Введите адрес электронной почты, который не обязательно уникальный для каждого пользователя. 7. Выберите No для разработчика, и оставьте значение No для администратора рабочего пространства. Имейте в виду, что привилегии безопасности, которые определяются этими двумя значениями, связаны со средой разработки Apex.Если вы не хотите, чтобы эти пользователи могли получить доступ к этой среде разработки, оставьте в покое администрирование рабочего пространства Apex, ведь важно сделать правильный выбор.
В этой области, вы можете также указать, что аккаунт заблокирован и не доступен, а также выставить требование ввода нового пароля пользователя при первом входе в приложение. Вы можете оставить по умолчанию настройки нового пароля или установить его значение в No,чтобы избежать путаницы. Это требование применяться только в случае, если пользователь пытается войти в приложение с помощью логина для сайта apex.oracle.com. Если пользователь входит непосредственно в приложение, как вы увидите в следующем разделе, APEX не запрашивать новый пароль. 8. После ввода этой информации нажмите кнопку Create и Create Another, чтобы начать процесс снова. 9. Создайте три пользователя с именами MANAGER, SALESREP, and USER. Для последнего пользователя, нажмите кнопку Create User, чтобы вернуться в на Manage Application Express Users, которая должна выглядеть как на рисунке 9-5.
neutrino150
16.08.12 в 10:50
|
|
Допустим у вас есть пользователи, которых надо научить использовать систему безопасности вашего приложения. Как это работает. Возможно, мысль о безопасности мелькала в вашей голове еще до этой главы. Вы запускаете приложения из среды разработки, но не хотите, чтобы ваши пользователи получали доступ к самой среде. Как вашим пользователям получать доступ к приложению напрямую? Чтобы ваши пользователи могли вызывать APEX приложения предоставьте им следующий URL: http://apex.oracle.com/pls/otn/f?p=application_number Другими словами, если номер вашего приложения равен 29390, URL будет выглядеть так: http://apex.oracle.com/pls/otn/f?p=29390 1. Выйдите из среды разработки APEX, нажав на ссылку Logout в правом верхнем углу. Введите адрес вашего приложения в панели навигации и нажмите клавишу ВВОД, чтобы открыть страницу входа в приложение, как показано на рисунке 9-6 2. Введите одно из имен пользователей которых вы создали, но при этом используйте неверный пароль. 3. Когда система отклонит неправильные данные, введите правильный пароль, чтобы открыть приложение, как показано на Рисунок 9-7.
neutrino150
17.08.12 в 11:19
|
|
Есть одна большая разница между тем, что показано на рисунке 9-7, и тем, что вы обычно видели – а именно, нет ссылок в нижней части страницы, позволяющих перейти непосредственно к среде разработки. Эта панель называется панелью инструментов разработчика и отображается только при запуске приложения из Application Builder. Конечные пользователи, получая доступ к приложению напрямую, не смогут войти в среду разработки и никогда не увидят эту панель в нижней части страницы. Вы можете попробовать зайти под остальными логинами, если хотите, но результат будет тем же. Все, что вы делали до сих пор, это определяли пользователей для процесса аутентификации. Все становится намного интереснее, когда вы используете эти удостоверения пользователей для разграничения прав доступа в приложении (авторизация).
neutrino150
20.08.12 в 07:44
|
|
Ограничение доступа. Создание пользователей - важный этап разграничения доступа к приложению. После создания пользователей, используйте следующую информацию для ограничения доступа к приложению или его компонентам.
Naias
11.07.12 в 10:49
|
|
Авторизация Авторизация определяет, какой доступ будут иметь пользователь или группы пользователей к различным компонентам приложения. Большинство компонентов приложения общедоступны, но можно для отдельных элементов определить какие пользователи имеют право использовать этот компонент. Авторизация реализуется с помощью схем авторизации. Как и аутентификация, схема авторизации используется, чтобы связать пользователей с определенным правами. Oracle APEX дает вам простой способ для определения и реализации схем авторизации с помощью списков контроля доступа или ACL. Хотя списки ACL не являются единственным способом ограничить доступ к компонентам, большинство приложений может использовать эту возможность с пользой.
neutrino150
21.08.12 в 09:28
|
|
Списки ACL APEX поставляется с тремя встроенными схемами авторизации: view, edit, and administrator. Схемы выстроены по иерархии, от view до administrator. Эта иерархия означает, что пользователи схемы edit в ACL автоматически получают все права доступа схемы view, а пользователи схемы administrator имеют привилегии и просмотра и редактирования списков ACL. Списки контроля доступа (ACL) реализуются путем создания страницы ACL, которая позволяет указать пользователей для различных списков ACL, а также как реализовать схему авторизации.
neutrino150
22.08.12 в 08:05
|
|
Попробуем вот это. Определение контроля доступа. Возможность контролировать доступ к вашему приложению скрыта. Вообще этот процесс связан с определением ACL страницы вашего приложения. 1. Вернемся к среде разработки, выйдя из приложения и снова зайдя в систему под учетной записью разработчика, затем нажмем кнопку Application Builder. Выберем наше приложение и нажмем кнопку Create page. 2. На следующей странице, нажмем на значок Access Control, чтобы начать создание страницы для управления ACL. 3. Введем номер страницы, или примем указанный по умолчанию, затем нажмем кнопку Next. 4. Выберем вариант использования существующего набора вкладок и добавим новую вкладку с названием ACL. Нажмем кнопку Next, а затем Finish, чтобы завершить создание новой страницы. Первоначальная настройка была простой – теперь разберемся в деталях.
neutrino150
27.08.12 в 08:32
|
|
Как это работает. Реальные трудности при использовании списков контроля доступа (ACLs) открываются при открытии страницы контроля доступа, которую вы только что создали. 1. Нажмите на значок Run, чтобы открыть страницу контроля доступа, как показано на рисунке 9-8. Есть два основных раздела на этой странице. В верхней части страницы вы можете определить способ, которым будут использоваться списки ACL в этом приложении. Первый вариант просто игнорирует все основанные на ACL ограничения на любые из компонент приложения. Следующий уровень немного повышает меры безопасности, позволяя пользователям, определенным в списке ACL, иметь доступ к приложению, хотя при этом любой пользователь, определенный в любом из списков, получает полный доступ ко всем функциям.
neutrino150
28.08.12 в 10:05
|
|
Третий вариант обеспечивает ограничения, описанные в ACL. По умолчанию есть три привилегии: Administrator, Edit, и View. Как упоминалось ранее, эти привилегии выстроены по иерархии, каждый более высокий уровень имеет и привилегии более низких уровней. Этот третий вариант реализации прав доступа вы пройдете в ближайшее время. Последний вариант ограничивает доступ к приложению для администраторов, кроме того эффективно блокирует приложение для всех, кроме самых привилегированных пользователей.
neutrino150
29.08.12 в 12:05
|
|
Техническая заметка - Еще больше уровней? Если вы создавали надежные схемы безопасности до этого, то теперь вы явно немного растеряны от представленной функциональности . В конце концов, три различных уровня безопасности не так уж много. Имейте в виду, что эти уровни предоставляется для вас по умолчанию и автоматически. В нижней части страницы вы можете связать пользователей с тремя различными ACL, что вы и проделаете в следующем разделе. Эти уровни реализованы в виде схем авторизации. Вы можете добавить больше схем авторизации вручную с помощью соответствующей ссылки на странице Shared Components. Тем не менее, ваши новые схемы не будут автоматически отображаться в пользовательском определении в нижней части страницы, в связи с тем, что этот список значений статический. Конечно, вы можете просто добавить свои схемы авторизации в этот статический список, это сделает их доступными в процессе выбора.
neutrino150
30.08.12 в 09:53
|
|
Попробуйте вот это. Определение пользователей. Для того чтобы увидеть схемы авторизации в действии, надо связать пользователей с конкретной схемой, это вы можете сделать в определенной области страницы ACL. Эта страница выглядит настолько привычно, что вы сразу понимаете, как добавлять пользователей, удалять пользователей и применять изменения с помощью соответствующих кнопок и флажков. В области контроля Access Control List, необходимо добавить имя пользователя для каждого из пользователей которых вы создали в первой части этой главы.
1. Создайте пользователя ADMIN с правами администратора. 2. Создайте пользователей MANAGER и SALESREP с правами редактирования. 3. Создайте пользователя USER привилегией View . 4. Добавить ваше имя пользователя и дайте себе права администратора. 5. Нажмите кнопку Apply Changes, чтобы связать пользователей с ACL.
Вы можете определить вашего пользователя-разработчика в качестве администратора, хотя и в этом случае вы сможете получить доступ к любой странице из среды разработки просто выключая авторизацию. Итак, вы заложили основу использования ACL как способа взаимодействия пользователя с приложением.
neutrino150
31.08.12 в 09:21
|
|
Попробуйте вот это. Ограничение доступа к отдельной вкладке. Определение пользователей и связь их с ACL образуют фреймворк для назначения привилегий доступа в вашем приложении. Но чтобы эти списки имели эффект вам придется добавить к компоненту в приложении схему авторизации. Ваша первая задача будет ограничить использование вкладки Администрирование только администраторами. 1. Вернитесь к среде разработки. Перейдите на страницу Shared Components и выберите Tabs. 2. Нажмите на вкладку Maintenance и нажмите на иконку Edit. Нажмите на кнопку авторизации, чтобы ограничить видимость в разделе, как показано на рис 9-9 (см список выбора). Есть семь вариантов выбора - разрешить или запретить доступ пользователям из списков управления доступом (ACL), или запретить доступ к любому, не включенному в списки ACL, так называемым Public пользователям. Для этой вкладки вы хотите запретить ее отображение для всех, кто не является администратором. 3. Выберите контроль доступа - администратор для этой вкладки и нажмите кнопку Apply Changes. Достаточно просто. Теперь взглянем на то, как новое ограничение доступа работает.
neutrino150
03.09.12 в 11:54
|
|
Вот как это работает. Пришло время увидеть списки управления доступом (ACL) в действии. 1. Вернитесь в среду разработки приложений, выберите ваше приложение, выберите первую страницу приложения и нажмите на значок Run, чтобы открыть первую страницу, которая выглядит, как показано на рисунке 9-10. Немного не то - вкладка Maintenance (техническое обслуживание) все еще видна. Но подождите, вы забыли войти в систему как пользователь, чье членство в ACL не позволит ему или ей увидеть нужную вкладку. 2. Нажмите Выход, а затем войдите с именем пользователя USER и паролем. Опа, не то. Почему до сих пор видны вкладки? Причина проста, вспомните, вы не активизировали ACL. 3. Щелкните на вкладке ACL, и поменяйте режим приложения на Public read only. Нажмите кнопку Set Application Mode, чтобы открыть страницу, показанную на рисунке 9-11. Так вот лучше. Вы можете выйти из системы и снова войти как ADMIN, чтобы убедиться, что списки ACL работают должным образом, позволяя этому пользователю увидеть страницу ACL. Красота. Но, если вы помните, вы использовали такой же список как на странице Maintenance на одной из других страниц. Вам придется подавить отображение этого списка, использую э ту же схему авторизации.
neutrino150
04.09.12 в 13:01
|
|
Попробуйте вот это. Ограничение доступа к области страницы. При создании списка общих компонентов со списком всех страниц технического обслуживания, вы также отображали этот список в специальном регионе на странице деталей заказа. Вы можете использовать ту же самую процедуру, чтобы скрыть, что регион. 1. Вернитесь к среде разработки, и перейдите к странице деталей заказа. В главе 7 вы удалили регион Тех. Обслуживание с этой страницы. Добавьте его обратно на эту страницу, щелкните знак плюс в области Регионы, указывая, что новый регион представляет собой список регионов; дайте региону название Техническое обслуживание и назначьте ему позицию 03; и выберите пункт Техническое обслуживание и нажмите кнопку Create List Region. 2. Кликните на регион Техническое обслуживание, а затем на кнопку авторизации, тогда появится раздел, который выглядит так же, как тот, который вы видели на вкладке. 3. Измените схему авторизации на “администратор”, и нажмите кнопку Apply Changes. Вот как это работает. Пришло время увидеть, что второй вариант ограничений доступа работает также как и первый. 1. Выйдите из приложения и снова войдите в систему под любым другим именем пользователя. Перейдите на вкладку Заказы и выберите строку заказа для редактирования. Страница деталей заказа не будет отображаться, как ожидалось. Использование списков контроля доступа, чтобы просто скрыть страницы и регионы – это выглядит немного грубовато. Вы можете использовать списки управления доступом (ACL) для конфигурирования функциональных возможностей, доступных для различных пользователей, путем контроля доступа к компонентам, которые обеспечивают эту функциональность.
neutrino150
05.09.12 в 09:49
|
|
Попробуйте вот это. Ограничение доступа к функциональности. К примеру, вы хотите, чтобы пользователи из списка ACL не могли добавлять новые заказы или редактировать существующие. Так как оба эти действия обеспечиваются специфическими компонентами в приложении, вы можете ограничить функциональность путем ограничения доступа к этим компонентам. Этими компонентами являются кнопка Create на странице заказов, которая позволяет пользователям создавать новый заказ, и первый столбец в этом отчете, который позволяет пользователям редактировать существующие записи. 1. Вернитесь к среде разработки и перейдите в отчет Заказы, который должен быть на Стр. 1. 2. Нажмите кнопку Create на странице, перейдите в раздел Авторизация атрибутов страницы, и выберите пункта access control – значение edit. При выборе этого параметра члены списков ACL Edit и Administrator получают доступ к этой кнопке, одновременно скрывая эту кнопку от глаз пользователей указанных в списке ACL. 3. Нажмите кнопку Apply Changes, чтобы сохранить внесенные изменения.
neutrino150
06.09.12 в 09:50
|
|
4. Нажмите на ссылку Интерактивный отчет. 5. Ниже в разделе Link Column выберите контроль доступа равный Edit для схемы авторизации этого столбца. 6. Нажмите кнопку Apply Changes, чтобы применить ACL ограничения.
Вот как это работает. Пришло время проверить вашу работу. 1. Нажмите на значок Run для страницы. Если вы в последние разы запускали приложение как ADMIN, MANAGER, или SALESREP, вы не заметили никаких отличий во внешнем виде страницы. 2. Нажмите Выход, а затем снова войти в программу как USER. Первая страница должна выглядеть как на Рисунке 9-12.
neutrino150
10.09.12 в 07:53
|
|
Вуаля! Оба объекта кнопка Create и ссылка Edit исчезли, как мы хотели. Попробуйте вот это. Ограничение доступа к вкладке ACL. Как вы видите, использование схем авторизации и ACL оказывают сильное влияние на ваши приложения - влияние настолько мощное, что вы очень вероятно, хотите, чтобы только самые привилегированные пользователи могли вносить изменения в ACL или использовать их в приложении. Другими словами, вы хотите, в значительной степени ограничить доступ к вкладке ACL. В данном конкретном случае, вы наделили администратора возможностью управления содержимым приложения, таким как продукты доступные для заказа. Но вам, конечно, не хотелось бы давать всем этим людям возможность отключать списки управления доступом (ACL) или изменения своего членства в списках ACL. Вы можете закрыть пользователям доступ к этой вкладке, а также к связанным с ней страницам, наложив условия на ее отображение. 1. Вернитесь в среду разработки, перейдите к Shared Components и нажмите на ссылку Tabs. 2. Выберите вкладку ACL, а затем нажмите на значок Edit на вкладке. Нажмите на кнопку Conditions, чтобы открыть раздел показано на рисунке 9-13
neutrino150
11.09.12 в 09:24
|
|
3. Нажмите на выпадающий список с типами условий. Этот список дает много вариантов, с возможностью создания условий, основанных на SQL запросах, блоках PL/SQL, запросах генерируемых страницей, значениях двух выражений , на типе браузера клиента, и это мы назвали только некоторые из вариантов. Для конкретной задачи, можно, если хотите, выбрать наиболее жесткие ограничительные условия.
neutrino150
12.09.12 в 11:39
|
|
4. Выберите значение Never. Звучит тяжко, но так надо. При таком условии, никто никогда не увидит эту вкладку. 5. Нажмите кнопку Apply Changes, чтобы сохранить новое условие. Это упражнение не только дает вам возможность запретить пользователям получать доступ к странице ACL, но и знакомит вас с идеей условного отображения элементов, эта идея будет детально рассмотрена в заключительном разделе этой главы.
Вот как это работает. Вы закрыли доступ к вкладке ACL для всех пользователей. Теперь важно убедиться, что доступ действительно закрыт. 1. Запустите приложение. Вы не увидите на вкладке ACL. Вы можете войти туда и выйти обратно в качестве каждого из пользователей, которых вы определили, чтобы продемонстрировать, что никто не сможет увидеть эту вкладку. 2. Вернитесь к среде разработки. Выберите страницу, ACL, и нажмите на значок Run, чтобы открыть страницу ACL. Указав, в свойствах вкладки ACL условие никогда не доступна, вы, по сути, блокировали единственный путь к странице ACL. Тем не менее, вы все еще можете запустить страницу из среды разработки. Данный способ ограничения доступа может не подходить для вашего приложения, однако вы изучили еще один вариант для ограничения доступа. Как вы увидели в этом разделе, ACL привносят большую гибкость именно в таблицы. Вам, конечно, хотелось бы рассмотреть их с точки зрения разрешения или ограничения доступа к компонентам приложения. Но могут быть случаи, когда вы захотите использовать еще более тонкий уровень контроля доступа, да последнем разделе этой главы мы покажем вам, как достичь этой цели.
neutrino150
13.09.12 в 09:30
|
|
Конфигурация доступа. В предыдущем разделе мы использовали тупой подход к ограничению доступа к компонентам приложения. Но вы можете сделать условным отображение большинства частей страницы и различных областей, вплоть до уровня отдельных элементов или столбцов. Чтобы открыть для себя гибкий контроль доступа в APEX, в этом разделе, вы решите задачу изменения отображения заказов в детальной форме, что позволит увеличить возможности менеджеров по сравнению с простыми торговыми представителями. Вспомните то, как вы добавляли PL / SQL процедуры в предыдущей главе, чтобы автоматически устанавливать дату отгрузки по заказу через три дня после его поступления.
Такой последовательный подход гарантирует определенный уровень удовлетворенности клиентов, но могут быть случаи, когда вы хотите ускорить доставку. В этом случае вы должны ограничить круг людей, которые могут изменить дату отгрузки по заказу. Например, вы не можете позволить сотрудникам отдела продаж изменить дату отгрузки, так как большинство продавцов хотят сделать все от них зависящее, чтобы их клиенты были счастливы, вплоть до немедленной отгрузки товара. Вы также не хотите, чтобы пользователь с правами администратора мог изменить дату отгрузки, так как эти пользователи не понимают бизнес правил, по которым вы затягиваете или ускоряете поставки для конкретного заказчика. Правильный путь в этом сценарии разрешить менеджеру изменять дату отгрузки. Вот как вы можете реализовать этот функционал - используйте условное отображение, которое будет делать поле дата отгрузки доступным только для чтения.
neutrino150
14.09.12 в 09:28
|
|
Попробуйте вот это. Ограничение доступа к элементам. Один из принципов дизайна в APEX – это предлагать необходимую функциональность разработчикам в легкой, декларативной форме. Требования типа: сделать определенные поля редактируемыми лишь при некоторых обстоятельствах, является ярким примером этого принципа. В этой ситуации, вы можете использовать отдельную опцию, чтобы получить результаты, которые вы хотите. 1. Вернитесь в среду разработки и выберите страницу деталей. 2. Нажмите на пункт Pn_ORDER_SHIP_DATE, а затем на кнопку Read Only, чтобы изолировать этот раздел как показано на рисунке 9-14.
neutrino150
18.09.12 в 12:23
|
|
Эта страница выглядит знакомо, что является данью уважения развитию среды APEX и вашего растущего знакомства с ней.
neutrino150
19.09.12 в 07:37
|
|
3. Выберите для Read Only следующее условие Value of Item in Expression 1 != Expression 2, а затем введите APP_USER in Expression 1 and С in Expression 2. Это небольшое изменение создаст требуемую функциональность. APP_USER это переменная сеанса, которая содержит, как ни странно, имя пользователя приложения. Допустим пользователь не MANAGER, тогда вы не хотите давать доступ к полю SHIP_DATE. Это новое изменение хорошо, но вам придется вернуться назад и изменить тип отображения поля SHIP_DATE, чтобы MANAGER мог использовать его. 4. Нажмите кнопку Name, чтобы вывести раздел, который содержит параметры отображения элемента. Измените значение Display As с Display Only на Date Picker (DD-MON-YYYY). 5. Нажмите кнопку Apply Changes. Так как только MANAGER может вставить или отредактировать значение поля, вы можете дать ему или ей возможность использовать date picker (календарик). Прежде, чем приложение начнет правильно работать, нужно сделать еще одно изменение. Как вы помните, SHIP_DATE вычисляется автоматически при сохранении записи. Эта операция имеет смысл, пока пользователь не является MANAGER. Таким образом, вы хотели бы добавить условие к вычислению, которое помешает его выполнению, если пользователь MANAGER. Но даже если пользователь MANAGER, вы все равно хотите, чтобы дать ему или ей возможность, использовать в приложении значение по умолчанию для SHIP_DATE. Вы можете настроить операции вычисления используя простое условие соединения. 6. Выберите вычисления для Pn_ORDER_TIMESTAMP. 7. Нажмите на кнопку Conditions, чтобы открыть раздел показанный на рисунке 9-15 в законченном виде.
neutrino150
20.09.12 в 08:50
|
|
8. Выберите PL/SQL Expression в качестве условия, и введите следующий код Expression 1: : APP_USER <> ' MANAGER ' OR :Pn_ORDER_SHIP_DATE IS NULL заменяя n номером вашей страницы деталей, и не забываем предварять имя поля двоеточием (:), чтобы определить его в качестве переменной связывания. С помощью этого кода, вы разрешаете проводить вычисления всякий раз, когда пользователь не является MANAGER, или когда пользователь не ввел значение в поле Pn_ORDER_SHIP_DATE. 9. Нажмите кнопку Apply Changes, чтобы сохранить свою работу. Вы завершили все изменения, которые предоставят именно ту функциональность которую вы хотите.
neutrino150
21.09.12 в 09:26
|
|
Вот как это работает. В конце концов, пришло время, увидеть вашу работу в действии. 1. Нажмите на значок Run, чтобы открыть страницу деталей. 2. Выйдите из приложения, и войдите как MANAGER. 3. Щелкните на одном из заказов в отчете, чтобы открыть страницу, показанную на рисунке 9-16. Вы можете видеть, что поле Ship Date представляет собой календарик. 4. Введите дату в поле Ship Date, и сохраните запись.
neutrino150
24.09.12 в 11:17
|
|
Обратите внимание, что введенная дата сохраняется как следует. 5. Выйдите из приложения, а затем снова войти в систему как пользователь ADMIN. 6. Нажмите на значок Edit любого из заказов, чтобы открыть страницу, показанную на рисунке 9-17.
neutrino150
25.09.12 в 11:08
|
|
Ну вот - та же страница, но поле Ship Date теперь отображается только как поле. Использование условий на поле и вычислений все это привело к необходимому вам результату, а сделали всего нескольких простых записей.
neutrino150
26.09.12 в 09:11
|
|
Техническая заметка - Группы пользователей - это спасение. Та функциональность, которую вы только что сделали, в реальном мире используется более чем одним человеком для редактирования даты. Можно достичь той же цели используя условия на основе группы пользователей, а не отдельного пользователя, и просто добавить всех необходимых пользователей в эту группу.
neutrino150
27.09.12 в 09:02
|
|
Для реализации сценария, вы, вероятно, хотите добавить некоторые проверки, которые будут применяться на дату введенную менеджером, гарантируя, что указанная дата не попадает на выходные или праздники.
Кроме того, вы, вероятно, хотите добавить условия для защиты даты заказа, или, если на то пошло, защитить информацию о заказе, если время, указанное в SHIP_DATE уже прошло. Теперь используя ваши знания об APEX, вы в состоянии легко применять ограничения в своих целях.
neutrino150
28.09.12 в 11:41
|
|
Резюме Эта глава добавляет последний штрих к вашим первоначальным исследованиям в разработке APEX. Вы узнали, как использовать встроенные функции безопасности среды разработки, формируя таким образом различные конфигурации доступа пользователей к данным и компонентам приложений. В этой главе вы: Определили дополнительных пользователей. Добавили этих пользователей к схемам аутентификации. Создали страницу ACL и схемы авторизации. Добавили пользователей к схемам аутентификации и использовали их для ограничения доступа. Использовали специальные условия для различных компонентов APEX заставляя безопасность работать. Вы должны сделать шаг назад и понять, что аутентификация и авторизация вашего приложение встроены в среду APEX. Хотя нужно было создавать пользователей и назначать контроль доступа для различных компонентов, этот процесс просто порождал определенные ограничения - вам не требовалось строить или добавлять новый каркас безопасности. Эта глава завершает краткое руководство по созданию приложений APEX. В остальной части этой книги, вы узнаете больше об управлении APEX приложениями, использованию пакетов приложений APEX, и рассмотрите возможность переноса существующих приложений в среде APEX.
neutrino150
02.10.12 в 15:06
|
|