Киришүү
Бул кароодо мен веб-тиркемелердин коопсуздугу сыяктуу теманы талкуулагым келет. Java коопсуздукту камсыз кылган бир нече технологияларга ээ:-
" Java SE Platform Security Architecture ", бул тууралуу кененирээк маалыматты Oracle колдонмосунан окуса болот: " JavaTM SE Platform Security Architecture ". Бул архитектура биз Java SE иштөө чөйрөсүндө биздин Java тиркемелерибизди кантип коргошубуз керектигин сүрөттөйт. Бирок бул биздин бүгүнкү сүйлөшүүбүздүн темасы эмес.
-
" Java Cryptography Architecture " бул маалыматтарды шифрлөөсүн сүрөттөгөн Java кеңейтүүсү. Бул кеңейтүү жөнүндө көбүрөөк JavaRush боюнча " Java криптографиясынын архитектурасы: Биринчи таанышуу " кароосунан же Oracle колдонмосунан окуй аласыз: " Java Cryptography Architecture (JCA) Reference Guide ".
JAAS
JAAS Java SE кеңейтүүсү жана Java Аутентификация жана Authorизация Кызматында (JAAS) маалымдама колдонмосунда сүрөттөлгөн . Технологиянын аты айтып тургандай, JAAS аутентификация жана авторизация кантип аткарылышы керектигин сүрөттөйт:-
" Аутентификация ": Грек тorнен которгондо "authentikos" "чыныгы, чыныгы" дегенди билдирет. Башкача айтканда, аутентификация – аныктыгын текшерүү. Аныктыгы текшерorп жаткандардын баары алар ким экенин айтышат.
-
" Authorization ": англис тorнен которгондо "уруксат" дегенди билдирет. Башкача айтканда, авторизация ийгorктүү аутентификациядан кийин аткарылган мүмкүндүктү башкаруу.
- анын айдоочулук күбөлүгү жол кыймылынын катышуучусу катары адамдын өкүлү катары
- анын паспорту, өз өлкөсүнүн жараны катары адамдын өкүлү катары
- анын чет өлкөлүк паспорту, эл аралык мамилелердин катышуучусу катары адамдын өкүлү катары
- китепканада анын китепкана картасы, китепканага тиркелген окурман катары адамдын өкүлү катары
Веб колдонмо
Ошентип, бизге веб-тиркеме керек. Gradle автоматтык долбоор куруу системасы бизге аны түзүүгө жардам берет. Gradleди колдонуунун аркасында биз кичинекей буйруктарды аткаруу менен Java долбоорун өзүбүзгө керектүү форматта чогулта алабыз, керектүү каталог түзүмүн автоматтык түрдө түзө алабыз жана башка көп нерселер. Сиз Gradle жөнүндө кененирээк кыскача баяндамадан окуй аласыз: " Градлга кыскача киришүү " же расмий documentацияда " Gradle Баштоо ". Биз долбоорду инициализациялашыбыз керек (Инициализация) жана бул үчүн Gradle атайын плагини бар: “ Gradle Init Plugin ” (Init Initialization үчүн кыска, эстеп калуу оңой). Бул плагинди колдонуу үчүн, буйрук сабында буйрукту иштетиңиз:gradle init --type java-application
Ийгorктүү аяктагандан кийин бизде Java долбоору болот. Эми редакциялоо үчүн долбоорубуздун куруу сценарийин ачалы. build.gradle
Куруу скрипти - бул колдонмонун түзүлүшүнүн нюанстарын сүрөттөгөн файл . Демек, аты, скрипт куруу. Бул долбоорду куруу сценарийи деп айта алабыз. Gradle - бул ар тараптуу курал, анын негизги мүмкүнчүлүктөрү плагиндер менен кеңейтилген. Ошондуктан, биринчи кезекте, "плагиндер" блогуна көңүл буралы:
plugins {
id 'java'
id 'application'
}
Демейки боюнча, Gradle, биз белгилеген " " ылайык --type java-application
, кээ бир негизги плагиндердин топтомун орнотту, башкача айтканда, Gradle дистрибуциясына кирген плагиндер. Эгер сиз gradle.org веб-сайтындагы "Документтер" (б.а. documentация) бөлүмүнө кирсеңиз , анда "Шилтеме" бөлүмүндөгү темалардын тизмесинде сол жакта " Негизги плагиндер " бөлүмүн көрөбүз, б.а. бул абдан негизги плагиндердин сүрөттөлүшү менен бөлүм. Келгиле, Gradle биз үчүн жараткан плагиндерди эмес, бизге керектүү плагиндерди тандайлы. Документтерге ылайык, " Gradle Java Plugin " Java codeу менен баштапкы codeду түзүү сыяктуу негизги операцияларды камсыз кылат. Ошондой эле, documentацияга ылайык, " Gradle тиркеме плагини " бизге "аткарылуучу JVM тиркемеси" менен иштөө үчүн куралдар менен камсыз кылат, б.а. өз алдынча тиркеме катары ишке кирүүчү java тиркемеси менен (мисалы, консолдук тиркеме же өзүнүн UI бар тиркеме). Көрсө, бизге "колдонмо" плагининин кереги жок экен, анткени... бизге өз алдынча колдонмонун кереги жок, бизге веб колдонмо керек. Аны жок кылалы. Ошондой эле бул плагинге гана белгилүү болгон "mainClassName" жөндөөлөрү. Андан ары, ошол эле " Таңгактоо жана бөлүштүрүү " бөлүмүндө Колдонмо плагининин documentтерине шилтеме берилген, Gradle War Pluginге шилтеме бар. Gradle War Plugin , documentацияда айтылгандай, согуш форматында Java веб тиркемелерин түзүүгө колдоо көрсөтөт. WAR форматында JAR архивинин ордуна WAR архиви түзүлөт дегенди билдирет. Бул бизге керек окшойт. Ошондой эле, documentацияда айтылгандай, "Согуш плагини Java плагинин кеңейтет". Башкача айтканда, биз java плагинин согуш плагинине алмаштыра алабыз. Ошентип, биздин плагин блогубуз акыры мындай болот:
plugins {
id 'war'
}
Ошондой эле "Gradle War Plugin" үчүн documentтерде бул плагин кошумча "Долбоор макетин" колдонот деп айтылат. Макет англис тorнен жайгашкан жер деп которулган. Башкача айтканда, согуш плагини демейки боюнча өз милдеттери үчүн колдоно турган файлдардын белгилүү бир жайгашкан жеринин болушун күтөт. Ал веб-тиркеме файлдарын сактоо үчүн төмөнкү каталогду колдонот: src/main/webapp
Плагиндин жүрүм-туруму төмөнкүчө сүрөттөлөт:
web.xml
- бул "Орнотуу дескриптору" же "жайгаруу дескриптору". Бул биздин веб тиркемени кантип иштөө үчүн конфигурациялоону сүрөттөгөн файл. Бул файл биздин колдонмобуздун кандай суроо-талаптарды аткара турганын, коопсуздук жөндөөлөрүн жана башка көптөгөн нерселерди көрсөтөт. Негизи, ал JAR файлындагы манифест файлына бир аз окшош (" Манифест файлдары менен иштөө: Негиздерди " караңыз). Манифест файлы Java Тиркемеси (б.а. JAR архиви) менен кантип иштөө керектигин айтат, ал эми web.xml Java веб тиркемеси (б.а. WAR архиви) менен кантип иштөө керектигин айтат. "Орнотуу Дескриптору" түшүнүгү өзүнөн өзү пайда болгон эмес, бирок documentте сүрөттөлгөн " Servlet API Specification"". Каалаган Java веб-тиркемеси ушул "Servlet API"ден көз каранды. Бул API экенин түшүнүү керек, башкача айтканда, бул кээ бир өз ара аракеттенүү келишиминин сүрөттөлүшү. Веб колдонмолору көз карандысыз тиркемелер эмес. Алар веб-serverде иштешет. , бул колдонуучулар менен тармактык байланышты камсыз кылат. Башкача айтканда, веб-server веб тиркемелери үчүн кандайдыр бир "контейнер" болуп саналат. Бул логикалуу, анткени биз веб-тиркеме логикасын жазгыбыз келет, б.а. колдонуучу кандай барактарды көрөт жана кантип алар колдонуучунун аракеттерине жооп бериши керек.Ал эми биз билдирүү колдонуучуга кантип жөнөтүлө тургандыгы, маалымат byteтары кандайча бериле тургандыгы жана башка төмөн деңгээлдеги жана өтө сапатты талап кылган нерселер үчүн code жазгыбыз келбейт. веб-тиркемелердин баары ар кандай экени көрүнүп турат, бирок маалыматтарды берүү бирдей.Б.а., бир миллион программисттер бир эле максат үчүн кайра-кайра code жазууга туура келет. жана маалымат алмашуу, ал эми веб-тиркеме жана иштеп чыгуучу ал маалыматтарды түзүү үчүн жооптуу. Ал эми бул эки бөлүктү бириктирүү үчүн, б.а. веб-server жана веб-тиркеме, сизге алардын өз ара аракеттенүүсү үчүн келишим керек, б.а. бул үчүн алар кандай эрежелерди карманышат? Келишимди кандайдыр бир түрдө сүрөттөп берүү үчүн, веб-тиркеме менен веб-serverдин ортосундагы өз ара аракеттенүү кандай болушу керек, Servlet API ойлоп табылган. Кызыктуусу, сиз Spring сыяктуу алHowтарды колдонсоңуз да, капоттун астында дагы эле Servlet API иштейт. Башкача айтканда, сиз Жазды колдоносуз, ал эми Жаз сиз үчүн Servlet API менен иштейт. Биздин веб-тиркеме долбоору Servlet API'ге көз каранды болушу керек экен. Бул учурда, Servlet API көз каранды болот. Белгилүү болгондой, Gradle ошондой эле долбоордун көз карандылыгын декларативдик түрдө сүрөттөөгө мүмкүнчүлүк берет. Плагиндер көз карандылыкты кантип башкарса болорун сүрөттөйт. Мисалы, Java Gradle Plugin "testImplementation" көз карандылыкты башкаруу ыкмасын киргизет, анда мындай көз карандылык тесттер үчүн гана керек деп айтылат. Бирок Gradle War Plugin көз карандылыкты башкаруу ыкмасын "providedCompile" кошот, анда мындай көз карандылык биздин веб тиркеменин WAR архивине киргизилбейт деп айтылат. Эмне үчүн биз WAR архивибизге Servlet API киргизбейбиз? Анткени Servlet API биздин веб-тиркемеге веб-serverдин өзү тарабынан берилет. Эгерде веб-server Сервлет API менен камсыз кылса, анда server сервлет контейнери деп аталат. Ошондуктан, бизге Сервлет API менен камсыз кылуу веб-serverдин милдети, ал эми СервлетAPIди code түзүлгөн учурда гана камсыз кылуу биздин милдетибиз. Ошол үчүн providedCompile
. Ошентип, көз карандылык блогу төмөнкүдөй болот:
dependencies {
providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
testImplementation 'junit:junit:4.12'
}
Ошентип, келгиле, web.xml файлына кайрылалы. Демейки боюнча, Gradle эч кандай Жайгаштыруу Дескрипторун түзбөйт, ошондуктан биз муну өзүбүз кылышыбыз керек. Каталог түзөлү src/main/webapp/WEB-INF
, анда биз XML файлын түзөбүз web.xml
. Эми "Java Servlet спецификациясын" жана " 14-БӨЛҮМ Жайгаштыруу Дескриптору " бөлүмүн ачалы . "14.3 Жайгаштыруу Дескриптору" бөлүмүндө айтылгандай, Жайгаштыруу Дескрипторунун XML documentи http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd схемасы менен сүрөттөлөт . XML схемасы document кандай элементтерден турушу мүмкүн экенин жана алар кандай тартипте пайда болушу керектигин сүрөттөйт. Кайсылары милдеттүү, кайсылары милдеттүү эмес. Жалпысынан алганда, ал documentтин түзүмүн сүрөттөйт жана XML documentинин туура түзүлгөнүн текшерүүгө мүмкүндүк берет. Эми " 14.5 Мисалдар " бөлүмүндөгү мисалды колдонолу , бирок схема 3.1 versionсы үчүн көрсөтүлүшү керек, б.а.
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd
Биздин бош web.xml
төмөнкүдөй болот:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<display-name>JAAS Example</display-name>
</web-app>
Эми JAAS аркылуу коргой турган сервлетти сүрөттөп көрөлү. Буга чейин Gradle биз үчүн App классын түзгөн. Аны сервлетке айландыралы. " 2-БӨЛҮМ Сервлет интерфейси " спецификациясында айтылгандай , " Көпчүлүк максаттар үчүн Иштеп чыгуучулар HttpServletти сервлеттерин ишке ашыруу үчүн кеңейтет ", башкача айтканда классты сервлет кылуу үчүн, сиз бул классты төмөнкүдөн мурасташыңыз керек HttpServlet
:
public class App extends HttpServlet {
public String getGreeting() {
return "Secret!";
}
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.getWriter().print(getGreeting());
}
}
Жогоруда айтылгандай, Servlet API server менен биздин веб-тиркеменин ортосундагы келишим болуп саналат. Бул келишим колдонуучу server менен байланышканда server колдонуучудан an object түрүндөгү суроо-талапты жаратып HttpServletRequest
, аны сервлетке өткөрүп берерин сүрөттөөгө мүмкүндүк берет. Ал ошондой эле сервлетти an object менен камсыздайт HttpServletResponse
, андыктан сервлет ага колдонуучу үчүн жооп жаза алат. Сервлет иштеп бүткөндөн кийин, server анын негизинде колдонуучуга жооп бере алат HttpServletResponse
. Башкача айтканда, сервлет колдонуучу менен түз байланышта эмес, server менен гана байланышат. Сервер бизде сервлет бар экенин жана ал кандай суроо-талаптар үчүн колдонулушу керек экенин бorши үчүн, бул тууралуу serverге жайгаштыруу дескрипторунда айтып беришибиз керек:
<servlet>
<servlet-name>app</servlet-name>
<servlet-class>jaas.App</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/secret</url-pattern>
</servlet-mapping>
Бул учурда, бардык суроо-талаптар класска туура келген /secret
ат менен биздин бир сервлетке жөнөтүлбөйт . Жогоруда айтылгандай, веб-тиркемени веб-serverде гана жайгаштырууга болот. Веб server өзүнчө орнотулушу мүмкүн (өз алдынча). Бирок бул карап чыгуунун максаттары үчүн альтернативалуу вариант ылайыктуу - камтылган serverде иштөө. Бул server программалык түрдө түзүлүп, ишке киргизилет (плагин муну биз үчүн жасайт) жана ошол эле учурда биздин веб-тиркеме ага жайгаштырылат дегенди билдирет. Gradle куруу системасы төмөнкү максаттар үчүн " Gradle Gretty Plugin " плагинин колдонууга мүмкүндүк берет :app
jaas.App
plugins {
id 'war'
id 'org.gretty' version '2.2.0'
}
Андан тышкары, Gretty плагининин жакшы documentтери бар . Gretty плагини ар кандай веб-serverлердин ортосунда которуштурууга мүмкүндүк бере турганынан баштайлы. Бул documentацияда кененирээк сүрөттөлгөн: " Сервлет контейнерлеринин ортосунда которулуу ". Келгиле, Tomcat'ка которулалы, анткени... бул колдонуудагы эң популярдуулардын бири, ошондой эле жакшы documentтер жана көптөгөн мисалдар жана талданган көйгөйлөр бар:
gretty {
// Переключаемся с дефолтного Jetty на Tomcat
servletContainer = 'tomcat8'
// Укажем Context Path, он же Context Root
contextPath = '/jaas'
}
Эми биз "gradle appRun" иштете алабыз, андан кийин биздин веб тиркеме http://localhost:8080/jaas/secret дарегинде жеткorктүү болот
Аутентификация
Аутентификация орнотуулары көбүнчө эки бөлүктөн турат: server тарабындагы орнотуулар жана ушул serverде иштеген веб-тиркеме тараптагы орнотуулар. Веб тиркемесинин коопсуздук жөндөөлөрү веб-serverдин коопсуздук орнотуулары менен өз ара аракеттениши мүмкүн, эгерде башка себепсиз веб-тиркеме веб-server менен өз ара аракеттене албаса. Биз бекеринен Tomcatка өткөн жокпуз, анткени... Tomcat жакшы сүрөттөлгөн архитектурага ээ (" Apache Tomcat 8 Архитектурасын " караңыз). Бул архитектуранын сүрөттөлүшүнөн көрүнүп тургандай, Tomcat веб-server катары веб-тиркемени белгилүү бир контекст катары көрсөтөт, ал " Tomcat Контекст " деп аталат. Бул контекст ар бир веб-тиркеме башка веб-тиркемелерден обочолонгон өзүнүн жөндөөлөрүнө ээ болууга мүмкүндүк берет. Кошумча, веб-тиркеме бул контексттин жөндөөлөрүнө таасир этиши мүмкүн. Ийкемдүү жана ыңгайлуу. Тереңирээк түшүнүү үчүн " Tomcat контексттик контейнерлерин түшүнүү " макаласын жана Tomcat documentациясынын " Контексттик контейнер " бөлүмүн окууну сунуштайбыз . Жогоруда айтылгандай, биздин веб тиркеме/META-INF/context.xml
. Жана биз таасир эте ала турган эң маанилүү орнотуулардын бири - Коопсуздук чөйрөсү. Коопсуздук чөйрөсү "коопсуздук аймагынын" бир түрү. Атайын коопсуздук жөндөөлөрү көрсөтүлгөн аймак. Демек, Коопсуздук чөйрөсүн колдонууда биз бул чөйрө үчүн аныкталган коопсуздук орнотууларын колдонобуз. Коопсуздук чөйрөлөрү контейнер тарабынан башкарылат, б.а. веб-server, биздин веб тиркеме эмес. Колдонмобузга кайсы коопсуздук чөйрөсүн кеңейтүү керектигин serverге гана айта алабыз. Tomcat documentациясы " Регитим компоненти " бөлүмүндө Realm колдонуучулар жана алардын аутентификацияны аткаруу үчүн ролдору жөнүндө маалыматтардын жыйындысы катары сүрөттөйт. Tomcat ар кандай Security Realm ишке ашырууларынын топтомун камсыз кылат, алардын бири " Jaas Realm ". Бир аз терминологияны түшүнгөндөн кийин, файлдагы Tomcat Контекстти сүрөттөп көрөлү /META-INF/context.xml
:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="JaasLogin"
userClassNames="jaas.login.UserPrincipal"
roleClassNames="jaas.login.RolePrincipal"
configFile="jaas.config" />
</Context>
appName
- өтүнмөнүн аталышы. Tomcat бул ысымды configFile
. configFile
- бул "логин конфигурация файлы". Мунун мисалын JAAS documentациясынан көрүүгө болот: " Тиркеме В: Кирүү конфигурацияларынын мисалы ". Кошумчалай кетсек, бул файлды ресурстардан биринчи издөө керек. Ошондуктан, биздин веб-тиркеме бул файлды өзү камсыздай алат. Атрибуттар userClassNames
жана roleClassNames
колдонуучунун негизги өкүлү болгон класстардын көрсөткүчтөрүн камтыйт. JAAS "колдонуучу" жана "рол" түшүнүктөрүн эки башка деп бөлөт java.security.Principal
. Жогорудагы класстарды сүрөттөп көрөлү. Колдонуучунун башкысы үчүн эң жөнөкөй ишке ашырууну түзөлү:
public class UserPrincipal implements Principal {
private String name;
public UserPrincipal(String name) {
this.name = name;
}
@Override
public String getName() {
return name;
}
}
Биз дал ошол эле ишке ашырууну кайталайбыз RolePrincipal
. Интерфейстен көрүнүп тургандай, Директор үчүн эң негизгиси - бул директорду билдирген кандайдыр бир аталышты (же ID) сактоо жана кайтаруу. Азыр бизде Коопсуздук чөйрөсү бар, бизде башкы класстар бар. Бул файлды " configFile
" атрибутунан толтуруу үчүн калды, ака login configuration file
. Анын сүрөттөлүшүн Tomcat documentациясынан тапса болот: " Realm Component ".
\src\main\resources\jaas.config
Келгиле, бул файлдын мазмунун орнотобуз:
JaasLogin {
jaas.login.JaasLoginModule required debug=true;
};
context.xml
Бул жерде жана бир эле ат колдонулганын белгилей кетүү керек . Бул Коопсуздук чөйрөсүн LoginModule менен картага түшүрөт. Ошентип, Tomcat Context бизге кайсы класстар жетекчилерди билдирерин, ошондой эле кайсы LoginModule колдонуу керектигин айтып берди. Биз эмне кылышыбыз керек, бул LoginModule ишке ашыруу болуп саналат. LoginModule , балким, JAASтеги эң кызыктуу нерселердин бири. Расмий documentтер LoginModuleди иштеп чыгууга жардам берет: " Java Authentication and Authorization Service (JAAS): LoginModule Developer's Guide ". Кирүү модулун ишке ашыралы. Келгиле, интерфейсти ишке ашырган класс түзөлү LoginModule
:
public class JaasLoginModule implements LoginModule {
}
Алгач биз инициализация ыкмасын сүрөттөп беребиз LoginModule
:
private CallbackHandler handler;
private Subject subject;
@Override
public void initialize(Subject subject, CallbackHandler callbackHandler, <String, ?> sharedState, Map<String, ?> options) {
handler = callbackHandler;
this.subject = subject;
}
Бул ыкма сактайт Subject
, биз аны андан ары текшерип, жетекчилер жөнүндө маалымат менен толтурабыз. Биз ошондой эле келечекте колдонуу үчүн сактайбыз CallbackHandler
, бизге берилген. Жардамы менен CallbackHandler
биз бир аздан кийин аутентификация предмети жөнүндө ар кандай маалыматты сурай алабыз. Бул тууралуу кененирээк CallbackHandler
documentациянын тиешелүү бөлүмүнөн окуй аласыз: " JAAS Reference Guide: CallbackHandler ". login
Андан кийин, аутентификация ыкмасы аткарылат Subject
. Бул аутентификациянын биринчи этабы:
@Override
public boolean login() throws LoginException {
// Добавляем колбэки
Callback[] callbacks = new Callback[2];
callbacks[0] = new NameCallback("login");
callbacks[1] = new PasswordCallback("password", true);
// При помощи колбэков получаем через CallbackHandler логин и пароль
try {
handler.handle(callbacks);
String name = ((NameCallback) callbacks[0]).getName();
String password = String.valueOf(((PasswordCallback) callbacks[1]).getPassword());
// Далее выполняем валидацию.
// Тут просто для примера проверяем определённые значения
if (name != null && name.equals("user123") && password != null && password.equals("pass123")) {
// Сохраняем информацию, которая будет использована в методе commit
// Не "пачкаем" Subject, т.к. не факт, что commit выполнится
// Для примера проставим группы вручную, "хардcodeно".
login = name;
userGroups = new ArrayList<String>();
userGroups.add("admin");
return true;
} else {
throw new LoginException("Authentication failed");
}
} catch (IOException | UnsupportedCallbackException e) {
throw new LoginException(e.getMessage());
}
}
login
Биз өзгөртпөшүбүз маанилүү Subject
. Мындай өзгөртүүлөр ырастоо методунда гана болушу керек commit
. Андан кийин, биз ийгorктүү аутентификацияны ырастоо ыкмасын сүрөттөшүбүз керек:
@Override
public boolean commit() throws LoginException {
userPrincipal = new UserPrincipal(login);
subject.getPrincipals().add(userPrincipal);
if (userGroups != null && userGroups.size() > 0) {
for (String groupName : userGroups) {
rolePrincipal = new RolePrincipal(groupName);
subject.getPrincipals().add(rolePrincipal);
}
}
return true;
}
login
Бул ыкманы жана бөлүү кызыктай сезorши мүмкүн commit
. Бирок кеп логин модулдарын айкалыштырса болот. Жана ийгorктүү аутентификация үчүн бир нече кирүү модулдары ийгorктүү иштеши үчүн зарыл болушу мүмкүн. Жана бардык керектүү модулдар иштеген болсо, анда өзгөртүүлөрдү сактаңыз. Бул аутентификациянын экинчи этабы. abort
жана ыкмалары менен аяктайлы logout
:
@Override
public boolean abort() throws LoginException {
return false;
}
@Override
public boolean logout() throws LoginException {
subject.getPrincipals().remove(userPrincipal);
subject.getPrincipals().remove(rolePrincipal);
return true;
}
Усул abort
аутентификациянын биринчи фазасы ишке ашпай калганда чакырылат. Метод logout
системадан чыкканда чакырылат. Биздикин ишке ашырып Login Module
, аны конфигурациялагандан кийин, азыр биз белгилүү бир колдонууну каалай турганыбызды Security Realm
көрсөтүшүбүз керек : web.xml
Login Config
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JaasLogin</realm-name>
</login-config>
Биз коопсуздук чөйрөбүздүн атын аныктап, аныктыгын текшерүү ыкмасын - BASIC көрсөттүк. Бул " 13.6 Аутентификация " бөлүмүндө Servlet API сүрөттөлгөн аутентификациянын түрлөрүнүн бири . Калды н
GO TO FULL VERSION