Да, это немного влияет на производительность, если мы ссылаемся на неиспользованный оператор импорта в нашем классе java. Компилятор Java проверяет ссылки, упомянутые в инструкции импорта, и на минутном уровне влияет на производительность вашего класса.
Спасибо
У меня была проблема, что я хотел избежать не только перенаправления, но также и самой аутентификации форм, чтобы заставить веб-API работать. Записи в web.config с тегом местоположения для API не помогли. Таким образом я использовал SuppressFormAuthenticationRedirect и HttpContext. Текущий. SkipAuthorization для подавления аутентификации в целом. Для идентификации отправителя, я использовал, например, UserAgent в Заголовке, но это, конечно, рекомендуемо, чтобы реализовать дальнейшие шаги аутентификации, например, проверку по сравнению с передающим IP или отправить другой ключ с запросом. Ниже вставляется в Global.asax.cs.
protected void Application_BeginRequest(object sender, EventArgs e)
{
if (HttpContext.Current.Request.UserAgent == "SECRET-AGENT")
{
AppLog.Log("Redirect suppressed");
HttpApplication context = (HttpApplication)sender;
context.Response.SuppressFormsAuthenticationRedirect = true;
HttpContext.Current.SkipAuthorization = true;
}
}
Посмотрите в вашем файле Web.config в configuration\authentication
.
Если там есть подэлемент forms
с атрибутом loginUrl
, удалите его и попробуйте снова.
После небольшого исследования, похоже, что FormsAuthenticationModule добавляет обработчик для события HttpApplicationContext.EndRequest
. В своем обработчике он проверяет код состояния 401 и вместо этого выполняет Response.Redirect (loginUrl)
. Насколько я могу судить, нет способа изменить это поведение, если вы хотите использовать FormsAuthenticationModule
.
В итоге я решил обойти это, отключив FormsAuthenticationModule
в web.config следующим образом:
<authentication mode="None" />
И затем сам реализовав Application_AuthenticateEvent
:
void Application_AuthenticateRequest(object sender, EventArgs e)
{
if (Context.User == null)
{
var oldTicket = ExtractTicketFromCookie(Context, FormsAuthentication.FormsCookieName);
if (oldTicket != null && !oldTicket.Expired)
{
var ticket = oldTicket;
if (FormsAuthentication.SlidingExpiration)
{
ticket = FormsAuthentication.RenewTicketIfOld(oldTicket);
if (ticket == null)
return;
}
Context.User = new GenericPrincipal(new FormsIdentity(ticket), new string[0]);
if (ticket != oldTicket)
{
// update the cookie since we've refreshed the ticket
string cookieValue = FormsAuthentication.Encrypt(ticket);
var cookie = Context.Request.Cookies[FormsAuthentication.FormsCookieName] ??
new HttpCookie(FormsAuthentication.FormsCookieName, cookieValue) { Path = ticket.CookiePath };
if (ticket.IsPersistent)
cookie.Expires = ticket.Expiration;
cookie.Value = cookieValue;
cookie.Secure = FormsAuthentication.RequireSSL;
cookie.HttpOnly = true;
if (FormsAuthentication.CookieDomain != null)
cookie.Domain = FormsAuthentication.CookieDomain;
Context.Response.Cookies.Remove(cookie.Name);
Context.Response.Cookies.Add(cookie);
}
}
}
}
private static FormsAuthenticationTicket ExtractTicketFromCookie(HttpContext context, string name)
{
FormsAuthenticationTicket ticket = null;
string encryptedTicket = null;
var cookie = context.Request.Cookies[name];
if (cookie != null)
{
encryptedTicket = cookie.Value;
}
if (!string.IsNullOrEmpty(encryptedTicket))
{
try
{
ticket = FormsAuthentication.Decrypt(encryptedTicket);
}
catch
{
context.Request.Cookies.Remove(name);
}
if (ticket != null && !ticket.Expired)
{
return ticket;
}
// if the ticket is expired then remove it
context.Request.Cookies.Remove(name);
return null;
}
}
Это на самом деле немного сложнее, но я в основном получил код, просмотрев реализацию FormsAuthenticationModule
в отражателе. Моя реализация отличается от встроенного FormsAuthenticationModule
тем, что он ничего не делает, если вы отвечаете 401 - никакого перенаправления на страницу входа в систему. Думаю, если это когда-нибудь станет требованием, я могу поместить элемент в контекст, чтобы отключить автоматическое перенаправление или что-то в этом роде.