wie validiert ASP.NET Identity (OAuthAuthorizationServerProvider) die Requests?
Ich habe folgende Situation:
public partial class Startup {
public void Configuration(IAppBuilder app) {
app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
var authServerOptions = new OAuthAuthorizationServerOptions() {
AllowInsecureHttp = true,
TokenEndpointPath = new PathString("/token"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
Provider = new SimpleOAuthProvider()
};
app.UseOAuthAuthorizationServer(authServerOptions);
app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions());
}
}
Der Provider:
public class SimpleOAuthProvider : OAuthAuthorizationServerProvider {
public override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context) {
context.Validated();
return Task.FromResult<object>(null);
}
public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context) {
var allowedOrigin = "*";
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { allowedOrigin });
var identity = new ClaimsIdentity(context.Options.AuthenticationType);
identity.AddClaim(new Claim(ClaimTypes.Name, context.UserName));
// ...
var props = new AuthenticationProperties(new Dictionary<string, string>();
var ticket = new AuthenticationTicket(identity, props);
context.Validated(ticket);
}
}
Wenn ich nun per Postman einen Request (mit einem gültigen Token) absetze, dann hätte ich erwartet, dass ich nun in ValidateClientAuthentication ankomme. Dem ist aber nicht so.
Die tokenbasierte Authentifizierung an sich funktioniert, wenn ich das Token entferne erhalte ich keinen Zugriff, auch wenn ich es verändere werde ich ausgesperrt.
Wo muss ich dann nun eingreifen, wenn ich nun aber noch eigene Validierungen per Request ausführen will?
ich möchte in einem Report ein Hintergrundbild ab Seite 2 anzeigen. Dazu habe ich folgenden Code in den Report eingefügt:
Public Function IsFirstPage()
Return Me.Report.Globals!PageNumber = 1
End Function
Um Code zu sparen, zeige ich das Vorgehen an der Hintergrundfarbe (was auch nicht funktioniert):
Expression der BackgroundColor Eigenschaft des Report-Body:
=IIF(Code.IsFirstPage(), "Red", "Green")
Lasse ich mir den Wert von Code.IsFirstPage() auf der jeweiligen Seite ausgeben, steht auf Seite 1 "True", ansonsten "False".
Hat jemand eine Idee warum das Setzen des Hintergrundes nicht funktioniert? Wird die Hintergrundfarbe nur einmal gerendert und gilt dann für alle Seiten?
Alternativ kann ich natürlich auf Seite 1 ein Panel einbauen und mit der Hintergrundfarbe weiß belegen, dass würde das Problem lösen.
Dennoch interessiert mich ob der Report dieses dynamische Verhalten nicht kann?
ich habe folgendes Problem. Auf dem Server A liegt ein WCF Service, welcher Daten an einen anderen WCF Service auf Server B weiterreicht. Die Daten die zu Server A kommen, sind auf Nachrichtenebene verschlüsselt.
Dazu habe ich mit dem Windows Zertifizierungsdienst eine eigen CA und die entsprechenden Zertifikate ausgestellt und eingespielt. Auch hat der ApplicationPool Account Leserechte auf den Private Key.
Im Eventlog treten allerdings bei jeder Verbindung folgende Fehler auf:
Wenn ich den WCFTrace aktiviere, erhalte ich noch folgendes:
Fehler
Der Konfigurationsevaluierungskontext wurde nicht gefunden
Die Daten kommen trotzdem alle da an wo sie hinsollen, also in der Datenbank. Aber hat jemand eine Idee was diese Fehler sind? Hat er ein Problem mit den Zertifikaten?
ich suche ein CMS was ein Ticktsystem für den Support mitbringt oder als Plugin nachinstalliert werden kann. Ach ja, es macht nichts, wenn es für die kommerzielle Nutzung frei ist bzw. wenig kostet. Gern hätte ich ein .NET basiertes System.
Mit fiel jetzt spontan DotNetNuke (frei für kommerzielle Nutzung, oder?) ein, in Verbindung mit oldturtle.net.
Hat jemand Erfahrungen damit oder kann Alternativen nennen?
Du kannst beliebige Datenquellen an einen Report übergeben. Hier mal ein Beispiel eines Client-Reports:
var dataSource = new ReportDataSource("dataSet", myCustomObjectList);
var localReport = new LocalReport();
localReport.DataSources.Clear();
localReport.DataSources.Add(dataSource);
Wenn Du den Report schon an den ReportViewer übergeben hast, musst Du ihn nicht instanziieren. Du erhälst ihn dann mit:
Das ist nun irgendwie ein Widerspruch.
Du nutzt keine anderen Attribute und nutzt auch NUR dieses - nichts MVC eigenes.
Das hast Du nicht gefragt und ich nicht behauptet!
Zitat von Abt
Was das TrySkip da im speziellen tut / soll weiß ich nicht.
Sorry, dann muss sich informieren, bevor man antwortet!
Zitat von Abt
Zudem sollte der Fehler Code eher 401(Unauthorized) sein und nicht 403 (Forbidden), oder?
Nein muss er nicht.
An alle anderen.
Nach ewigen versuchen habe ich dann einen "wirklich" guten Tip im Internet gefunden, mit welchem das ganze jetzt augenscheinlich funktioniert.
Folgende Zeile muss im if-Zweig ergänzt werden:
filterContext.Result = new EmptyResult();
Warum es in einer anderen Anwendung funktioniert hat und meiner aktuellen nicht, muss ich jedoch noch ergründen.
ich habe ein Filter der sich um ein Weiterleiten auf die Loginseite, im Falle eines Timeouts bei Ajax Aufrufen, kümmern soll.
Leider kommt ständig die Fehlermeldung 'Server cannot set status after HTTP headers have been sent'. Ich benutze FormsAuthentication.
Hat jemand eine Idee, an was es liegen könnte? Ich hatte den gleichen Code in einer anderen Anwendung laufen, allerdings mit einem MembershipProvider. Es ist der einzige Unterschied.
public class AjaxAuthorizeAttribute : AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
if (filterContext.HttpContext.Request.IsAjaxRequest())
{
filterContext.HttpContext.Response.StatusCode = 403;
filterContext.HttpContext.Response.TrySkipIisCustomErrors = true;
filterContext.HttpContext.Response.End();
}
else
{
base.HandleUnauthorizedRequest(filterContext);
}
}
Funktioniert nicht heißt, dass die Form immer valid ist, auch wenn ich nichts ausfülle. Firebug sagt gar nichts, keine Meldung. Im MVC 3 wird die Form richtig validiert, nämlich als invalid, da ja nichts aufgefüllt ist, somit wird ein unnötiger Post verhindert.
ich möchte ein Formular clientseitig validieren und nur im gültigen Fall ein Post zum Server erlauben. Dieser Code funktioniert in einem MVC 3 Projekt, allerdings nicht mit MVC 4. Hat einer eine Idee und Kenntnisse darüber, dass evtl. noch ein Bug in der MVC 4 Preview vorliegt?
Model:
public class ContactModel
{
[Required]
public string FirstName { get; set; }
[Required]
public string LastName { get; set; }
}
Die Funktion Ajax.BeginForm ist allerdings nicht in jquery.unobtrusive-ajax.js enthalten, sondern in MicrosoftAjax.js
Microsoft hat MicrosoftAjax.js( das man ohnehin in MVC3 Anwendungen nicht nutzen solle ) und MicrosoftMvcAjax.js als veraltet deklariert und man soll stattdessen jQuery in der Originalfassung verwenden; was durchaus sinn macht.
MicrosoftAjax.js ist das Erste (alle anderen MicrosoftAjax files ebenfalls) was ich gelöscht habe, nach dem ich das Projekt angelegt habe. Somit sollte die Aussage nicht unbedingt Bestand haben.
Dieser Code wird in Chrome und IE problemlos ausgeführt. FireFox hingegen zeigt im FireBug den folgenden Fehler:
Fehler
Node cannot be inserted at the specified point in the hierarchy" code: "3
(function(a,b){function cg(a){return d...a:a+"px")}}),a.jQuery=a.$=d})(window);
kennt jemand dieses Problem oder hat eine Erklärung dafür?
hab es gesehen. Dann ist durch die Globalen Filter das Application_Error Event wohl unnötig. Der "richtigere" Weg scheint dann wohl ein eigenes HandleErrorAttribute zu sein, in dem ich die HttpRequestValidationException behandle.
Also benötigt man das Application_Error Event nicht mehr?
ich habe eine MVC 3 Anwendung und möchte die HttpRequestValidationException im Application_Error fangen. Dies funktioniert auch, so lange customErrors auf Off steht. Schalte ich customErrors auf On, komme ich bei dieser Exception nicht mehr im Application_Error an. Es scheint also das die Fehlerbehandlung hinter customErrors eher greift.
Ich hab das jetzt mit einer normalen ASP.NET 4.0 Anwendung getestet und da funktioniert es genau so, wie ich es erwarte. Ich kommt als erstes in Application_Error an.
Silverlight hat bei Microsoft keine große Zukunft mehr, stattdessen setzt man in Redmond auf HTML5. Zwar wird Silverlight 5 wohl noch erscheinen, in Microsofts Planungen spielt die einst als Flash-Konkurrent gestartete Technik aber offenbar keine große Rolle mehr.