Что такое страница с ошибкой белой метки

Когда пользователь пытается получить доступ к сайту, иногда он может столкнуться со страницей ошибки Whitelabel, которая является частью веб-хостинговой платформы, используемой для управления сайтом. Эта страница ошибки может вызвать немалое беспокойство пользователей, поскольку она не содержит никакой информации о том, что пошло не так и как решить эту проблему.

Страница ошибки Whitelabel генерируется веб-хостингом, который предоставляет пользователю платформу управления своим сайтом. Она демонстрирует, что сайт по некоторой причине не доступен и в настоящее время недоступен для использования. Эта ситуация может быть вызвана множеством факторов: неполадки в работе сервера, настройки DNS, проблемы с кэшированием и т.д.

Однако, не стоит отчаиваться, если вы столкнулись со страницей ошибки Whitelabel. Существует несколько способов, которые можно попробовать для решения проблемы и получения доступа к своему сайту. В этой статье мы рассмотрим некоторые из этих методов и дадим рекомендации по тому, как справиться с этой страницей ошибки.

Что такое страница ошибки whitelabel и как её исправить?

Страница ошибки whitelabel – это страница, которая появляется, когда пользователь сталкивается с ошибкой при доступе к веб-приложению. Обычно это происходит, когда некоторые ресурсы, необходимые для работы приложения, не загружаются или недоступны.

На странице ошибки whitelabel обычно выводится сообщение об ошибке, а также некоторая информация о возникшей проблеме. Также могут быть указаны рекомендации по решению проблемы.

Чтобы исправить страницу ошибки whitelabel, в первую очередь необходимо определить причину возникшей ошибки. Обычно это связано с недоступностью какого-то из ресурсов, например, базы данных или веб-сервера.

Если причина ошибки неочевидна, можно обратиться к логам приложения или использовать инструменты для отслеживания проблем. Нужно убедиться, что не возникли проблемы с кодом приложения, а также проверить, что все необходимые ресурсы доступны и правильно настроены.

В некоторых случаях исправление ошибки может потребовать изменений в коде приложения или в его настройках. Если проблему не удается решить самостоятельно, можно обратиться к разработчикам приложения или к специалистам по веб-разработке.

Причины появления страницы ошибки whitelabel

Whitelabel – это термин, обозначающий недописанные компоненты или методы, которые применяются как заглушки, чтобы не задерживать процесс разработки. В результате, при появлении проблемы с приложением, на экране может появиться страница ошибки с надписью «Whitelabel Error Page».

Наиболее распространенными причинами появления страницы ошибки whitelabel в Java-приложениях являются:

• Ошибка при запуске приложения: при развертывании приложения на сервере может произойти ошибка, если конфигурация приложения не совпадает с параметрами сервера. В результате может появиться страница ошибки whitelabel.
• Ошибка при подключении к базе данных: если приложение не может подключиться к базе данных, это вызовет ошибку. Часто при этом показывается страница ошибки whitelabel.
• Ошибки в коде приложения: ошибки, связанные с программным кодом приложения, также могут вызвать появление страницы ошибки whitelabel. Обычно это происходит при допущении ошибки в Java-коде, которые не были обработаны.

Как избежать ошибок Whitelabel?

• Проверяйте конфигурацию приложения перед запуском
• Документируйте свой код и обрабатывайте исключения
• Добавляйте контрольные точки и логирование
• Выполняйте регулярное обслуживание, проверяйте базу данных на ошибки

Способы решения проблемы страницы ошибки whitelabel

Если вы столкнулись с проблемой страницы ошибки whitelabel, есть несколько способов решения этой проблемы:

• Перезагрузите страницу: иногда страница ошибки появляется из-за временных проблем с сервером, и ее можно исправить просто перезагрузкой страницы;
• Очистите кэш вашего браузера: если страница ошибки появляется постоянно, то возможно проблема заключается в кэше вашего браузера. Попробуйте очистить кэш и посмотрите, исправит ли это проблему;
• Переустановите расширения вашего браузера: иногда проблема страницы ошибки может быть вызвана конфликтом между расширениями вашего браузера. Попробуйте переустановить или отключить некоторые расширения, чтобы устранить эту проблему;
• Свяжитесь с технической поддержкой: если ничто из вышеперечисленного не помогло, то, вероятно, проблема заключается в стороне сервера. Свяжитесь с технической поддержкой хостинга и сообщите о проблеме, чтобы они смогли исправить ее.

Вопрос-ответ

Что такое страница ошибки whitelabel?

Страница ошибки whitelabel — это страница, которая появляется в случае, если пользователь попытается обратиться к несуществующей странице на сайте. Эта страница часто имеет общий дизайн с основным сайтом, но может нести совсем другую информацию. При этом в адресной строке она содержит название компании, а не домен сайта. Данный тип страницы используется в том случае, когда владелец сайта не хочет, чтобы пользователи видели стандартную страницу ошибки, которую предоставляет сервер.

Автор оригинала: baeldung.

1. Обзор

В этой статье мы рассмотрим, как отключить и настроить страницу ошибок по умолчанию для приложения Spring Boot , поскольку правильная обработка ошибок свидетельствует о профессионализме и качестве работы.

2. Отключение страницы с ошибкой белой метки

Во-первых, давайте посмотрим, как мы можем полностью отключить страницу ошибок с белой меткой, установив для свойства server.error.whitelabel.enabled значение false:

server.error.whitelabel.enabled=false

Добавление этой записи в файл application.properties отключит страницу с ошибкой и отобразит краткую страницу, созданную из базового контейнера приложения, например Tomcat.

Мы можем достичь того же результата, исключив ErrorMvcAutoConfiguration компонент. Мы можем сделать это, либо добавив эту запись в файл свойств:

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration

#for Spring Boot 2.0
#spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.web.servlet.error.ErrorMvcAutoConfiguration

Или добавив эту аннотацию в основной класс:

@EnableAutoConfiguration(exclude = {ErrorMvcAutoConfiguration.class})

Все методы, упомянутые выше, отключат страницу ошибок с белой меткой. Это оставляет нас перед вопросом о том, кто же тогда на самом деле обрабатывает ошибку?

Ну, как упоминалось выше, обычно это базовый контейнер приложения. Хорошо то, что мы можем дополнительно настраивать вещи, показывая наши пользовательские страницы ошибок вместо всех значений по умолчанию – это основное внимание в следующем разделе.

3. Отображение Пользовательских Страниц Ошибок

Сначала нам нужно создать пользовательскую страницу ошибок HTML.

Мы сохраним файл как error.html так как мы используем Thymeleaf механизм шаблонов:

Something went wrong! 
Our Engineers are on it
Go Home

Если мы сохраним этот файл в каталоге ресурсы/шаблоны , он будет автоматически подхвачен контроллером BasicErrorController весенней загрузки по умолчанию .

Это все, что нам нужно для отображения нашей пользовательской страницы ошибок. С некоторой стилизацией у нас теперь будет гораздо более приятная страница ошибок для наших пользователей:

Мы можем быть более конкретными, назвав файл кодом состояния HTTP, который мы хотим использовать, например, сохранив файл как 404.html в ресурсы/шаблоны/ошибка означает, что он будет явно использоваться для 404 ошибок.

3.1. Пользовательский контроллер ошибок

Ограничение до сих пор заключается в том, что мы не можем запускать пользовательскую логику при возникновении ошибок. Чтобы достичь этого, мы должны создать компонент контроллера ошибок, который заменит компонент по умолчанию.

Для этого мы должны создать класс, реализующий Контроллер ошибок интерфейс , и переопределить его метод getErrorPath () , чтобы вернуть пользовательский путь для вызова при возникновении ошибки.

Однако, начиная с версии 2.3.x, Spring Boot устарел этот метод, и вместо этого для указания пользовательского пути следует использовать свойство server.error.path .

Но поскольку он все еще является частью интерфейса Контроллера ошибок и не был удален полностью, нам нужно будет переопределить его, иначе компилятор пожалуется. Чтобы обойти проблему здесь, мы возвращаем null , так как это в любом случае будет проигнорировано:

@Controller
public class MyErrorController implements ErrorController  {

    @RequestMapping("/error")
    public String handleError() {
        //do something like logging
        return "error";
    }

    @Override
    public String getErrorPath() {
        return null;
    }
}

В приведенном выше фрагменте мы также аннотируем класс с помощью @Controller и создаем сопоставление для пути, указанного в качестве свойства server.error.path:

Таким образом, контроллер может обрабатывать вызовы по пути /ошибка .

В HandleError () мы возвращаем пользовательскую страницу ошибок , созданную ранее. Если мы сейчас вызовем ошибку 404, то будет отображена наша пользовательская страница.

Давайте еще больше укрепим Ошибка управления() для отображения определенных страниц ошибок для различных типов ошибок.

Например, у нас могут быть красиво оформленные страницы, специально предназначенные для 404 и 500 типов ошибок. Затем мы можем использовать код состояния HTTP ошибки, чтобы определить подходящую страницу ошибки для отображения:

@RequestMapping("/error")
public String handleError(HttpServletRequest request) {
    Object status = request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);
    
    if (status != null) {
        Integer statusCode = Integer.valueOf(status.toString());
    
        if(statusCode == HttpStatus.NOT_FOUND.value()) {
            return "error-404";
        }
        else if(statusCode == HttpStatus.INTERNAL_SERVER_ERROR.value()) {
            return "error-500";
        }
    }
    return "error";
}

Затем, например, для ошибки 404 мы увидим error-404.html страница:

4. Заключение

С помощью этой информации мы можем теперь более элегантно обрабатывать ошибки и показывать вашим пользователям эстетичную страницу.

Как всегда, полный исходный код доступен на Github .

0, краткое описание

Перед изучением этой заметки лучше всего иметь некоторое представление о Spring mvc и Tomcat, чтобы было удобнее понимать.Если вам нужно знать наиболее прямое решение, перетащите его вниз, чтобы увидеть образец кода.

Вводится настоящая причина появления белой страницы Springboot. Основная причина заключается в том, что нет подходящей ситуации соответствия и возникает ситуация 404. Затем перейдите к системной по умолчанию сначала ErrorPage, которая представляет собой содержимое белой страницы, а затем с трех точек зрения в соответствии с его спецификой. , 1. Перехватчик, 2. Новая страница ошибок, 3. Пользовательская маршрутизация / маршрутизация ошибок для решения проблемы, а также знакомство с преимуществами и недостатками каждого метода, включая основные причины ошибок страницы цикла и т. Д.

1. Страница ошибки Whitelabel

То, что называется страницей ошибок Whitelabel (также называемой белой страницей), является страницей описания аномального HTTP-запроса в SpringBoot, как показано ниже.

image

Содержимое белой страницы будет отображать код состояния, путь и причину ошибки, но реальная среда публикации онлайн-генерации обычно не допускает такой ситуации, и больше — это настраиваемые страницы 404 или 500 страниц.

Итак, теперь мы пришли к пониманию, в какой ситуации будут появляться белые страницы и как решить эту проблему. Давайте воспользуемся случаем 404, чтобы понять причину.

Перейти непосредственно к классу DispatcherServletprotected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws ExceptionМетод, содержащий фрагменты кода

mappedHandler = getHandler(processedRequest);
// находим подходящий обработчик запроса
if (mappedHandler == null || mappedHandler.getHandler() == null) {
         // В принципе, если вы его не найдете, введите здесь и установите код статуса ответа 404
         // Но после отладки так и не вошел сюда
    noHandlerFound(processedRequest, response);
    return;
}

В методе getHandler будет выполняться обход HandlerMapping в текущем веб-контейнере, чтобы найти соответствующий обработчик

image

image

Из приведенного выше рисунка очевидно, что текущий удобный обработчик — SimpleUrlHandlerMapping, потому что URL-адрес содержит/**, Все URL-адреса могут быть сопоставлены,Не войдет в noHandlerFound позади, Обработчик адаптации HandlerAdapter — это объект, созданный HttpRequestHandlerAdapter.

Не удается найти соответствующий ресурс в mv = ha.handle (loadedRequest, response, mappedHandler.getHandler ()), установите код состояния ответа на 404Подробнее см. Метод handleRequest класса ResourceHttpRequestHandler.

Теперь это эквивалентно установке кода состояния запроса на 404, больше ничего не делается, mv также равно null

В это время вам нужно вернуться к процессу вызова Tomcat. Если вы запрашиваете процесс вызова Tomcat, вы должны знать, что когда Tomcat получает запрос сокета Socket на соединителе, он упаковывается в запрос, ответ и другую информацию, которая будет отправлена ​​в Engine-> Host и другие компоненты. Он доставляется слой за слоем, затем принимается конвейером каждого компонента, а затем фильтруется соответствующим клапаном (клапаном) слой за слоем.

На этот раз дошел до класса StandardHostValveprivate void status(Request request, Response response)метод

private void status(Request request, Response response) {
        int statusCode = response.getStatus();
                 // Просмотр текущего кода состояния, текущий пример - 404
                 // Получить текущий контекст
        Context context = request.getContext();
        if (context == null) {
            return;
        }

        if (!response.isError()) {
                           // Текущий запрос верен
                           // это атомарный класс AtomicInteger errorState, если он больше 0, это считается ошибкой
             
            return;
        }

        ErrorPage errorPage = context.findErrorPage(statusCode);
                 // Об этом месте поговорим позже, это решение, устанавливаем страницу ошибки
        if (errorPage == null) {
            // Look for a default error page
            errorPage = context.findErrorPage(0);
        }
        if (errorPage != null && response.isErrorReportRequired()) {
            ...

image

Объедините код и диаграмму, а затем внимательно прочтите белую страницу.This application has no explicit mapping for /error, Маршрут error, причина отсюда, а затем переход вперед, адрес маршрута error

image

Белая страница mv, предоставляемая SpringBoot, используется позже для визуализации содержимого белой страницы, которую мы видим.

Пока что весь процесс выполнен,Подводя итог, это запрос несуществующей ссылки, которая перенаправляется в запрос / error после того, как обнаруживается, что это запрос 404.

Тогда решение очень простое, есть три решения, но эти три решения под разными углами, чтобы решить проблему.

• Добавить перехватчик
• Добавить ErrorPage
• Добавить / путь ошибки

2. Решите проблему с белой страницей.

2.1, добавить перехватчик

public class CustomHandlerInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
            Object handler) throws Exception {
                         // Должно быть истиной, иначе перехватчик не сработает
                         // Конечно, вы можете перехватывать любые URL-адреса по желанию
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
            ModelAndView modelAndView) throws Exception {
            if (modelAndView != null) {
                             // Предотвращаем нулевые указатели
                             // Если это страница с ошибкой в ​​springboot, определенно не будет отображаться, что mv имеет значение null
              modelAndView.setViewName("/err");
                             // Примечание: этот запрос является всего лишь пробным и не имеет практического значения
           }
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response,
            Object handler, Exception ex) throws Exception {
    }
}

@Bean
public WebMvcConfigurerAdapter customMvcConfigurerAdapter (){
    return new WebMvcConfigurerAdapter() {
        @Override
        public void addInterceptors(InterceptorRegistry registry) {
            registry.addInterceptor(new CustomHandlerInterceptor()).addPathPatterns("/**");
                         // добавляем перехватчик
            super.addInterceptors(registry);
        }
    };
}

После того, как перехватчик перехватит запрос / error, он вынужден изменить mv, так что последний отрендеренный mv для пробного использования является нашей настраиваемой настройкой, а не содержимым белой страницы, где mv самой белой страницы будет проходитьАнализатор представления ContentNegotiatingОбработка становитсяErrorMvcAutoConfiguration$WhitelabelErrorViewConfiguration

Обратите внимание, что все это истечение фактически было обработано 3 HTTP-запросами,На следующем рисунке показана информация журнала, распечатанная с использованием мониторинга событий HTTP.

image

Пройдите через / abc ==> jump / err ==> jump / error (содержимое не отображается, потому что содержимое, отправленное в браузер, было отображено с помощью / err

Реальный поток обработки вызовов состоит в том, что / abc не находит подходящий обработчик, а затем решает передать его на путь / error для обработки, но он перехватывается перехватчиком и перенаправляется в / err для обработки.

Недостатки: все запросы для этого маршрута будут перехвачены, включая статические файлы ресурсов, что не оказывает большого влияния на внутренние службы, которые предоставляют чистые интерфейсы. Другие службы будут иметь влияние

2.2, добавьте ErrorPage

Добавление подходящей ErrorPage не приведет к переходу к пути по умолчанию / ошибке перехватчика, а перейдет к настраиваемой ErrorPage. Причина этого была указана в методе статуса выше.

@Bean
public EmbeddedServletContainerCustomizer containerCustomizer() {
    return new EmbeddedServletContainerCustomizer() {
        @Override
        public void customize(ConfigurableEmbeddedServletContainer configurableEmbeddedServletContainer) {
            ErrorPage errorPage400 = new ErrorPage(HttpStatus.BAD_REQUEST,"/400");
            ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND,"/404");
            ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR,"/500");
            configurableEmbeddedServletContainer.addErrorPages(errorPage400,errorPage404,errorPage500);
        }
    };
}

 // ======= разделительная линия

 @ApiOperation («запрос 404»)
@GetMapping("404")
public String e404() {
    return "404";
}

В приведенном выше коде добавлено несколько путей перехода к странице ошибки ErrorPage и соответствующие им коды ошибок HTTP. В нашем текущем примере должен быть выполнен переход к соединению / 404, а затем как я могу получить сообщение об ошибке после его выполнения? В принципе, он должен отображать 404 Содержимое файла .html и классическая страница ошибок Tomcat отображаются одновременно, как показано на следующей странице, и содержимое вывода журнала.

image

image

Это проблема скачка петли

Когда в системе не указан преобразователь четкого представления, система будет использовать свой собственный преобразователь по умолчанию.InternalResourceView, Он проверит текущий URL-адрес перед отображением. Если обнаружится, что запрошенный URL-адрес соответствует целевому URL-адресу, он будет определенВперед сампоявляютсяCircular view pathЭта проблема

protected String prepareForRendering(HttpServletRequest request, HttpServletResponse response)
        throws Exception {

    String path = getUrl();
    if (this.preventDispatchLoop) {
        String uri = request.getRequestURI();
        if (path.startsWith("/") ? uri.equals(path) : uri.equals(StringUtils.applyRelativePath(uri, path))) {
            throw new ServletException("Circular view path [" + path + "]: would dispatch back " +
                    "to the current handler URL [" + uri + "] again. Check your ViewResolver setup! " +
                    "(Hint: This may be the result of an unspecified view, due to default view name generation.)");
        }
    }
    return path;
}

Итак, как ее решить, нужно исходить из фундаментальной цели

• Добавьте синтаксический анализатор шаблона, чтобы синтаксический анализатор по умолчанию не использовался
• Изменить путь перехода

Вы можете понять конкретные решения самостоятельно.В этой статье не используется отрисовка механизма шаблонов, а непосредственно отображаются основные данные.

@RequestMapping("/")
@RestController
public class ErrorController {

         @ApiOperation («запрос 404»)
    @GetMapping("404")
    public String e404() {
        System.out.println("404............");
                 return "Это действительно страница 404, посмотрите на нее";
    }

image

2.3, путь добавления / ошибки

Как вы знаете выше, поскольку система по умолчанию переходит к / error и завершает рендеринг данных, недостаточно настроить маршрут / error и избежать проблемы отсутствия статических ресурсов, но обратите внимание, что есть Один вопрос, подробности см. На рисунке ниже

image

image

Во-первых, я добавил и определил очень простой метод обработки пути ошибки, но при запуске Springboot есть 3 метода обработки пути ошибки, и они одновременно принадлежат одному и тому же дескриптору.Правила маршрутизации URLОбработка, выберите ручку в автоконфигурации,Это должно было привести к тому, что наш заказ / ошибка недействительны

image

После тестирования он действительно недействителен, и белая страница все еще отображается, так как это решить? Есть несколько способов сделать то же самое

• В соответствии с правилами сопоставления маршрутизации измените соответствующий контент, чтобы при окончательном выборе процессора он достиг нашего пользовательского процессора, но это очень сложно. Вам необходимо очень четко понимать правила сопоставления маршрутизации самого Spring mvc, чтобы гарантировать, что сопоставление URL-адресов Приоритетные вопросы, требующие решения, и т. Д.

• Мы уже знаем, что эти три / ошибки находятся в картографе маршрутов RequestMappingHandlerMapping.Мы можем сделать так, чтобы пользовательский процессор не сохранялся в карте маршрутов, и сделать Spring приоритетом согласованного преобразователя маршрутов при опросе. Да, но на самом деле BeanNameUrlMapping в handlerMapping все еще находится после RequestMappingHandlerMapping, если вы измените порядок, это также очень сложно

   

  image

EndpointHandlerMapping — это конечная точка в исполнительном модуле Springboot. Настроить конечную точку сложно, и она не подходит для текущего проекта.

Использование SimpleUrlHandlerMapping не подходит для Springboot. Если вы используете конфигурацию xml, вы можете напрямую установить ее URL-адрес. Это будет очень удобно. Если вы применяете метод аннотации в springboot, требуется дополнительная настройка, как показано в следующем коде

@RequestMapping("/")
@Controller
public class SimpleUrlController {

    private static final String ERROR_PATH = "/error";

    @Resource
    private SimpleUrlHandlerMapping simpleUrlHandlerMapping;

    @PostConstruct
    public void init() {
        Map<String, Object> map = new HashMap<>();
        map.put(ERROR_PATH, this);
        simpleUrlHandlerMapping.setUrlMap(map);

        simpleUrlHandlerMapping.initApplicationContext();
                 // Вызываем отображение simpleurl
    }

    @GetMapping("/error")
    @ResponseBody
    public String error(HttpServletRequest request) {
        System.out.println("SimpleUrlController");
        Enumeration<String> attributes = request.getAttributeNames();

        Map<String, Object> map = new HashMap<String, Object>();
        while (attributes.hasMoreElements()) {
           String name = attributes.nextElement();
           if (name.startsWith("java")) {
                               // Помните, что свойства самой пружины не должны быть выставлены снаружи!
               Object value = request.getAttribute(name);
               map.put(name, value);
           }
        }
        return JSON.toJSONString(map);
    }
}

image

Хотя / error вводится в SimpleUrlHandlerMapping, он все равно будет отображаться, даже если добавлена ​​дополнительная конфигурацияНет ошибки адаптера，Этот метод не применим

Оглядываясь назад на наблюдение BasicErrorController, мы можем унаследовать интерфейс ErrorController сами.

@RequestMapping("")
@Controller
public class CustomErrorController implements ErrorController {

    private static final String ERROR_PATH = "/error";

    @GetMapping(ERROR_PATH)
    @ResponseBody
    public String error(HttpServletRequest request) {
        System.out.println("CustomErrorController");
        Enumeration<String> attributes = request.getAttributeNames();

        Map<String, Object> map = new HashMap<String, Object>();
        while (attributes.hasMoreElements()) {
           String name = attributes.nextElement();
           if (name.startsWith("java")) {
                               // Помните, что свойства самой пружины не должны подвергаться воздействию извне!
               Object value = request.getAttribute(name);
               map.put(name, value);
           }
        }
        return JSON.toJSONString(map);
    }

    @Override
    public String getErrorPath() {
        return ERROR_PATH;
    }
}