Поправка Реацт и Спринг Боот ЦОРС проблема: Блокиран ГЕТ захтев

Разумевање ЦОРС грешака у Спринг Боот и Реацт апликацијама

Приликом развоја веб апликација користећи Реаговати за фронтенд и Спринг Боот за позадину, уобичајен проблем са којим се програмери суочавају је злогласна грешка ЦОРС. Ова грешка се јавља када прегледач блокира захтев из безбедносних разлога, посебно када покушава да се повеже са позадинском услугом хостованом на другом порту или домену. У овом случају имате посла са ЦОРС проблемом док правите а ГЕТ захтев са Реацт на Спринг Боот АПИ.

Порука о грешци обично указује да прегледач блокира ваш захтев јер је Аццесс-Цонтрол-Аллов-Оригин заглавље или недостаје или је погрешно конфигурисано. Вреди напоменути да су алати попут Поштар немојте спроводити ова безбедносна ограничења, због чега ваш захтев може савршено да функционише у Постман-у, али не успе у прегледачу.

У вашем сценарију, порука о грешци указује да захтев пре објављивања не пролази проверу контроле приступа. Ово се обично дешава када одређена заглавља или методе нису дозвољени или правилно конфигурисани у ЦОРС политици сервера. Иако се чини да је конфигурација ЦОРС-а на месту на страни сервера, можда постоје специфични проблеми у вези са начином на који обрађује захтеве претраживача.

Овај чланак ће вам помоћи да разумете основни узрок проблема и води вас кроз могућа решења за његово решавање ЦОРС грешка у вашој апликацији Реацт и Спринг Боот.

Руковање ЦОРС грешкама у Реацт и Спринг Боот апликацијама

Горе наведене скрипте имају за циљ да реше проблем ЦОРС грешке у Реацт фронтенд и Спринг Боот бацкенд подешавању. Грешка се јавља када фронтенд, хостован на 'хттп://лоцалхост:8081', покуша да упути ГЕТ захтев за Спринг Боот АПИ хостован на 'хттп://лоцалхост:8080'. Прегледачи примењују строга безбедносна правила како би спречили неовлашћене захтеве са више извора, због чега постоје ове ЦОРС смернице. Тхе ВебМвцЦонфигурер класа у позадинској конфигурацији Спринг Боот-а помаже у дефинисању ЦОРС правила која дозвољавају специфично порекло и методе, на крају решавајући проблем.

У позадини, датотека `ЦорсЦонфиг.јава` дефинише конфигурациону класу Спринг Боот. Тхе @Беан и @Оверриде напомене се користе за убацивање и прилагођавање ЦОРС конфигурације. У методи `аддЦорсМаппингс()`, функција `алловедОригинс()` експлицитно дозвољава захтеве са 'хттп://лоцалхост:8081', обезбеђујући да претраживач препозна ово порекло као поуздан извор. Укључивање `алловедМетходс()` осигурава да су све ХТТП методе, укључујући ГЕТ, ПОСТ и ОПТИОНС, дозвољене. Ово је кључно јер прегледачи обично шаљу захтев ОПТИОНС пре објављивања да би проверили да ли је стварни ГЕТ захтев дозвољен.

На фронтенду, Реацт управља захтевима користећи Акиос, популаран ХТТП клијент. У функцији `фетцхДата` датотеке `ПројецтПаге.тск`, функција `акиос.гет()` шаље ГЕТ захтев позадинском делу Спринг Боот-а. Опција `витхЦредентиалс` је постављена на тачно, што омогућава слање колачића и акредитива за аутентификацију уз захтев. Додатно, заглавље ауторизације је укључено да проследи токен корисника, обезбеђујући да је захтев исправно аутентификован. Без ових конфигурација, претраживач би блокирао захтев из безбедносних разлога.

На крају, датотека за тестирање јединице, `ЦорсТест.јава`, потврђује да ЦОРС конфигурација ради како се очекује. Овај тест симулира ХТТП ОПТИОНС захтев за позадински АПИ, који имитира стварни захтев пре прегледа који је направио прегледач. Тест проверава да ли одговор садржи исправна заглавља, као нпр Аццесс-Цонтрол-Аллов-Оригин, који дозвољава захтеве за више порекла са фронтенда. Метода `МоцкМвцРесултМатцхерс.хеадер()` обезбеђује да сервер исправно реагује на захтеве пре објављивања. Укључујући јединичне тестове, програмери могу осигурати да њихова ЦОРС конфигурација буде поуздана и функционална у различитим окружењима.

// CorsConfig.java
@Configuration
public class CorsConfig implements WebMvcConfigurer {
   @Override
   public void addCorsMappings(CorsRegistry registry) {
      registry.addMapping("/")
              .allowedOrigins("http://localhost:8081")
              .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
              .allowedHeaders("*")
              .allowCredentials(true);
   }
}

// ProjectPage.tsx
const ProjectsPage = () => {
   const [projectsData, setProjectsData] = useState<ProjectsData[]>([]);
   const projectsUrl = 'http://localhost:8080/api/projects/admin/toinspection';
   useEffect(() => { fetchData(); }, []);
   const fetchData = async () => {
      const token = Cookies.get('token');
      try {
         const response = await axios.get<ProjectsData[]>(projectsUrl, {
            headers: { "Content-Type": "application/json", Authorization: `Bearer ${token}` },
            withCredentials: true
         });
         setProjectsData(response.data);
      } catch (error) {
         console.error("Error fetching projects:", error);
      }
   };
   return (
      <div>
         <AdminPageTemplate type="projects" children=<AdminModContent data={projectsData} />/>
      </div>
   );
};
export default ProjectsPage;

// CorsTest.java
@RunWith(SpringRunner.class)
@WebMvcTest
public class CorsTest {
   @Autowired
   private MockMvc mockMvc;
   @Test
   public void testCorsHeaders() throws Exception {
      mockMvc.perform(MockMvcRequestBuilders.options("/api/projects/admin/toinspection")
              .header(HttpHeaders.ORIGIN, "http://localhost:8081")
              .header(HttpHeaders.ACCESS_CONTROL_REQUEST_METHOD, "GET"))
              .andExpect(MockMvcResultMatchers.status().isOk())
              .andExpect(MockMvcResultMatchers.header().exists("Access-Control-Allow-Origin"))
              .andExpect(MockMvcResultMatchers.header().string("Access-Control-Allow-Origin", "http://localhost:8081"));
   }
}

Истраживање ЦОРС-а у контексту безбедности и дизајна АПИ-ја

Када се бавите ЦОРС (Унакрсно дељење ресурса) у модерним веб апликацијама, кључно је разумети безбедносне импликације које стоје иза тога. ЦОРС се имплементира као безбедносна мера од стране претраживача како би се спречило злонамерне веб локације да неовлашћено упућују АПИ захтеве у име корисника. Ово је посебно важно у сценаријима у којима се осетљиви подаци размењују између фронтенд и бацкенд услуга, као што су токени за аутентификацију и кориснички акредитиви. Приликом постављања ЦОРС-а у позадину Спринг Боот-а, неопходно је дозволити само поузданим изворима да приступе заштићеним ресурсима, чинећи безбедносну конфигурацију кључним елементом архитектуре система.

Други кључни аспект је руковање захтевима пре објављивања, који су аутоматски захтеви које прегледач шаље пре стварног ГЕТ или ПОСТ захтева. Ово се дешава када клијент треба да потврди да ли сервер дозвољава захтеве са више извора и подржава одређена заглавља или методе. У неким случајевима, погрешне конфигурације у руковању њима захтеве пре лета може изазвати проблеме, што резултира грешкама ЦОРС чак и када стварни захтев добро функционише у алатима као што је Постман. Конфигурисање Спринг Боот-а `ЦорсРегистри` са правим заглављима и методама обезбеђује да се захтеви за префлигхт исправно обрађују, омогућавајући глатку интеракцију између фронтенда и бацкенд-а.

Штавише, руковање ЦОРС-ом не би требало да буде статично или јединствено за све. У динамичким окружењима попут оних којима се управља помоћу микросервиса, различити АПИ-ји могу имати различите безбедносне захтеве. Неки АПИ-ји ће можда морати да изложе само одређене методе, док други могу захтевати строжију контролу над пореклом. Ово је место где фино подешавање ЦОРС конфигурације за сваку крајњу тачку постаје важно. Правилно управљање ЦОРС-ом такође помаже у оптимизацији перформанси АПИ-ја тако што смањује непотребне захтеве пре објављивања и обезбеђује несметану интеракцију корисника.