ความปลอดภัยในฤดูใบไม้ผลิ
Spring Security เป็นกรอบความปลอดภัยที่สามารถให้บริการโซลูชั่นการควบคุมการเข้าถึงที่ปลอดภัยสำหรับโครงการ J2EE มันขึ้นอยู่กับตัวกรอง servlet ตัวกรองเหล่านี้สกัดกั้นการร้องขอขาเข้าและดำเนินการประมวลผลความปลอดภัยบางอย่างก่อนที่แอปพลิเคชันจะดำเนินการตามคำขอ
สปริงความปลอดภัยสกัดกั้นคำขอของผู้ใช้ดังนี้:
พื้นหลัง
ในโครงการที่แยกออกจากปลายด้านหน้าและด้านหลัง Springsecurity ใช้เป็นกรอบความปลอดภัยและ JWT ใช้เพื่อดำเนินการจัดการการอนุญาตเพื่อปรับปรุงความปลอดภัยของ RESTFUL API สิ่งแรกที่ฉันพบคือปัญหาข้ามโดเมน แต่ในระหว่างกระบวนการดำเนินการตามคำขอ JWT เซิร์ฟเวอร์ไม่สามารถรับ JWT ได้
ปัญหาข้ามโดเมน
ในระหว่างกระบวนการพัฒนาฉันพบปัญหาของ CORS (การแบ่งปันทรัพยากรข้ามโดเมน) ฉันเพียงแค่ตั้งค่าการเข้าถึงข้ามโดเมนทางฝั่งเซิร์ฟเวอร์ แต่มันเกิดขึ้นในระหว่างกระบวนการดำเนินการตามคำขอ JWT
เนื่องจาก JWT ถูกวางไว้ในส่วนหัวคำขอจึงไม่สนใจการประมวลผลข้ามโดเมนคือการเพิ่มฟิลด์ส่วนหัวที่อนุญาตให้ตั้งค่าตัวเอง
@componentpublic คลาส Corsfilter ใช้ตัวกรอง {logger logger = loggerFactory.getLogger (corsfilter.class); @Override เป็นโมฆะสาธารณะ init (FilterConfig FilterConfig) พ่น ServleTexception {} @Override โมฆะสาธารณะ dofilter (servletRequest servletrequest, servletResponse servletresponse, filterchain filterchain) httpservletResponse response = (httpservletResponse) servletResponse; Response.Setheader ("การควบคุมการควบคุม-Ollow-Origin", request.getheader ("Origin")); Response.Setheader ("การควบคุมการควบคุม-Ollow-Origin", "*"); //response.setheader("access-control-allow-methods","post, get,options,delete, put "); // วิธีการร้องขอที่อนุญาตให้ใช้การตอบสนอง setheader ("การควบคุมการควบคุม-หัว", "*"); Response.SetheAder ("การควบคุมการควบคุม-หัว", "X-Requested-with, แคชควบคุม, Pragma, ประเภทเนื้อหา, การอนุญาต"); // วิธีการร้องขอที่อนุญาตให้ใช้การตอบสนอง setheader ("การควบคุมการควบคุม-อนุญาต-credentials", "true"); // วิธีการร้องขอที่อนุญาตให้ใช้การตอบสนอง setheader ("การควบคุมการควบคุม-อนุญาต-credentials", "true"); // ว่าจะอนุญาตให้มีการร้องขอด้วยข้อมูลการตรวจสอบ FilterChain.dofilter (ServletRequest, ServletResponse); } @Override โมฆะสาธารณะทำลาย () {}} ค้นหาออนไลน์กล่าวว่าจำเป็นต้องดำเนินการตามคำขอตัวเลือกและส่งคืน 200 แต่การทดสอบไม่ได้ผล
คำขอตัวเลือกที่นี่เป็นคำขอ preflight จริงๆ
คำขอ preflight
แต่ปัญหายังไม่ได้รับการแก้ไขดังนี้
หลังจาก Google เป็นที่รู้จักเกี่ยวกับข้อมูลเกี่ยวกับคำขอ preflight
เมื่อเราเรียกอินเทอร์เฟซพื้นหลังเรามักจะพบว่าเราได้ร้องขอสองครั้ง ในความเป็นจริงครั้งแรกที่เราส่งคือคำขอ preflight (คำขอ preflight)
ทำไมคุณต้องมีคำขอ preflight
เราทุกคนรู้ว่านโยบายของเบราว์เซอร์เดียวกันคือด้วยเหตุผลด้านความปลอดภัยเบราว์เซอร์จะ จำกัด การร้องขอ HTTP ข้ามโดเมนที่เริ่มต้นจากสคริปต์ XMLHTTPREQUEST และดึงข้อมูลทั้งหมดเป็นไปตามนโยบายของต้นกำเนิดเดียวกัน
โดยทั่วไปมีสองวิธีสำหรับเบราว์เซอร์ในการ จำกัด คำขอข้ามโดเมน:
เบราว์เซอร์ จำกัด การออกคำขอข้ามโดเมนและคำขอข้ามโดเมน คำขอข้ามโดเมนสามารถเริ่มต้นได้ตามปกติ แต่ผลลัพธ์ที่ส่งคืนจะถูกดักโดยเบราว์เซอร์
โดยทั่วไปเบราว์เซอร์ จำกัด คำขอข้ามโดเมนในวิธีที่สองนั่นคือคำขอมาถึงเซิร์ฟเวอร์และอาจทำงานกับข้อมูลในฐานข้อมูล อย่างไรก็ตามผลที่ส่งคืนนั้นถูกสกัดกั้นโดยเบราว์เซอร์ดังนั้นเราจึงไม่สามารถรับผลตอบแทนได้ นี่เป็นคำขอที่ล้มเหลว แต่อาจส่งผลกระทบต่อข้อมูลในฐานข้อมูล
เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้นข้อมูลจำเพาะกำหนดให้สำหรับวิธีการร้องขอ HTTP นี้ที่อาจมีผลข้างเคียงบนข้อมูลเซิร์ฟเวอร์เบราว์เซอร์จะต้องใช้วิธีตัวเลือกก่อนเพื่อเริ่มคำขอ preflight เพื่อทราบว่าเซิร์ฟเวอร์อนุญาตให้มีการร้องขอข้ามโดเมน: หากได้รับอนุญาตให้ส่งคำขอจริงกับข้อมูลหรือไม่ หากไม่ได้รับอนุญาตให้ป้องกันการส่งคำขอจริงด้วยข้อมูล
เบราว์เซอร์แบ่งการร้องขอ CORS ออกเป็นสองประเภท: คำของ่าย ๆ และคำขอที่ไม่ง่าย
คำของ่ายๆ
1. วิธีการร้องขอเป็นหนึ่งในสามวิธีต่อไปนี้
2. ข้อมูลส่วนหัวของ HTTP ไม่เกินฟิลด์ต่อไปนี้
ใครก็ตามที่ไม่ตรงตามสองเงื่อนไขข้างต้นในเวลาเดียวกันคือคำขอที่ไม่ง่าย
เบราว์เซอร์จัดการคำขอทั้งสองนี้แตกต่างกัน
ไม่มีคำของ่ายๆ
คำขอที่ไม่ง่ายเป็นคำขอที่มีข้อกำหนดพิเศษสำหรับเซิร์ฟเวอร์เช่นวิธีการร้องขอหรือลบหรือประเภทของฟิลด์ประเภทเนื้อหาคือแอปพลิเคชัน/JSON
คำขอ CORS ที่ไม่ใช่คำของ่ายๆจะเพิ่มคำขอแบบสอบถาม HTTP ก่อนการสื่อสารอย่างเป็นทางการซึ่งเรียกว่าคำขอ "preflight" (preflight)
สำหรับการอ้างอิงรายละเอียดเพิ่มเติมเกี่ยวกับ CORS โปรดดูลิงค์ที่ด้านล่าง
สารละลาย
ในพื้นหลังของเราความปลอดภัยของสปริงใช้เป็นกรอบความปลอดภัยและไม่มีการประมวลผลที่สอดคล้องกันกับคำขอ preflight ดังนั้นคำขอนี้จะทำให้การควบคุมการอนุญาตล้มเหลว
นอกจากนี้ยังง่ายมากในการประมวลผล คุณจะต้องเพิ่มคำขอ preflight รีลีสลงในวิธีการกำหนดค่าคลาส Spring Security Configuration
@Override Void Protected Configure (httpsecurity http) พ่นข้อยกเว้น {http // เนื่องจากเราใช้ JWT เราไม่จำเป็นต้องใช้ csrf .csrf (). ปิดการใช้งาน () // ตามโทเค็นเราไม่จำเป็นต้องใช้เซสชัน คำขอ/ถูกปล่อยออกมา requestmatchers (corsutils :: ispreflightrequest) .permitall () // ปล่อย preflight.antmatchers ("/*"). permitall () .AntMatchers ("/u"). denyall () .AntMatchers ("/api/**"). permitall () .AntMatchers ("/v2/api-docs", "/การกำหนดค่า/ui", "/swagger-resources/**", "/configuration .AntMatchers ("/v2/api-docs", "/การกำหนดค่า/ui", "/swagger-resources/**", "/configuration/**" ,"/swagger-ui.html", "/webjars/**") คำขอยกเว้นข้างต้นจำเป็นต้องมีการตรวจสอบสิทธิ์ใด ๆ // ปิดการใช้งานแคช http.headers (). cachecontrol (); // เพิ่มตัวกรอง jwt http.addfilterbefore (AuthenticationTokenFilterbean (), UserNamePasswordauthenticationFilter.class); // เพิ่มการประมวลผลที่ไม่ได้รับอนุญาต http.exceptionhandling (). การรับรองความถูกต้องของ Point (getAuthenticationEntryPoint ()); // การอนุญาตไม่เพียงพอจัดการ http.exceptionhandling (). AccessDeniedHandler (getaccessdeniedhandler ()); -ในที่สุดปัญหาได้รับการแก้ไข!
สรุป
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่าเนื้อหาของบทความนี้จะมีค่าอ้างอิงบางอย่างสำหรับการศึกษาหรือที่ทำงานของทุกคน หากคุณมีคำถามใด ๆ คุณสามารถฝากข้อความไว้เพื่อสื่อสาร ขอบคุณสำหรับการสนับสนุน Wulin.com
อ้างถึง:
front-end | การอภิปรายสั้น ๆ เกี่ยวกับคำขอ preflight
การแบ่งปันทรัพยากรข้ามโดเมน CORS คำอธิบายโดยละเอียด