[Topic unique] .Net @ Prog

Recherche :

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 66 67 68 .. 77 78 79 80 81 82 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [Topic unique] .Net @ Prog

Yor_le_Bourrin

Reprise du message précédent :
Ca commence à être tendu donc. Dernière hypothèse TEntity.id est bien un string aussi dans ce cas ? Dans le cas contraire, possible que le cast ne soit pas géré. Genre string[].Contains(string) se traduit, string[].Contains(object) non

Publicité

Implosion du Sord

Fesseur de chameaux

J'y ai pensé mais le champs Id de mon entité est bien un string quand j'observe les objets

Pour le moment j'ai contourné le problème en faisant ça :

Code :

var r = await _dbSet.ToListAsync();
List<TEntity> objects = r.Where(a => ids.Contains(a.Id)).ToList();
return objects;

Je récupère tous mes objets qui sont en base, puis filtre dans mon backend
En temps normal, si je voie quelqu'un faire ça je le lapide... [:antp]
Heureusement que le jeu de données n'est pas ouf en taille même dans le cas le plus défavorable (car on est bien dans un code ultra générique ici, un "BaseRepository" )

(en tous cas merci Taiche et Yor_le_Bourrin pour votre aide)

Message édité par Implosion du Sord le 31-08-2020 à 16:15:57

---------------
Away from keyboard, close to your breast

TotalRecall

Pour le 2e souci tu peux confirmer que :

Code :

public virtual async Task<IDictionary<TPrimaryKey, TEntity>> GetByIdAsync(IEnumerable<TPrimaryKey> ids)
{
var bidules = ids.Take(10).ToList<string>();
var objects = await _dbContext.Set<TEntity>().Where(r => bidules.Contains(r.id)).ToListAsync()
return objects.ToDictionary(x => x.Id);
}

Plante exactement pareil ?
Juste pour être sûr que l'IEnumerable ids est évalué avant la conversion LINQ to SQL, et avec un nombre d'élément et un type acceptables.

Message édité par TotalRecall le 02-09-2020 à 08:12:18

---------------
Topic .Net - C# @ Prog

Implosion du Sord

Fesseur de chameaux

Le soucis reste identique.
En général je n'ai qu'un seul élément dans ma liste, donc le volume n'est pas un soucis [:tinostar]

Notons que je ne peux pas tester strictement ce que tu demandes car TPrimaryKey n'est pas forcément un string (il y a des cas où c'est un entier, d'autres des Guid) et donc .ToList<string> refuse de compiler.
J'ai donc fait un truc comme ça :

Code :

public virtual async Task<IDictionary<TPrimaryKey, TEntity>> GetByIdAsync(IEnumerable<TPrimaryKey> ids)
{
var bidules = (ids.Take(10) as IEnumerable<string> ).ToList<string>();
var objects = await _dbContext.Set<TEntity>().Where(r => bidules.Contains(r.id as string)).ToListAsync()
return objects.ToDictionary(x => x.Id);
}

J'avais testé en injectant une List<string> statique aussi. Même soucis

Vu que pour le moment j'ai une solution de contournement et que le jeu de données est petit, je vais attendre le retour d'un gars dans l'équipe et lui refiler le truc.
J'aime pas EF

---------------
Away from keyboard, close to your breast

ixemul

Nan mais sans blague ! ⚡

C'est quand je vois des trucs comme ça que je suis bien content de faire du SQL à la main et du mapping avec Dapper

Message cité 1 fois

---------------
VA APPRENDRE ET REVIENS QUAND TU SAIS, SINON ABSTIENT TOI C'EST UN GRAND CONSEIL QUE JE TE DONNE... TU ES INCOMPÉTENT ET C'EST UNE RÉALITÉ, TU N'AS RIEN A FAIRE ICI FAUT S'Y CONNAITRE ... -Jojo1998 - RIP - http://tinyurl.com/qc47ftk

Implosion du Sord

Fesseur de chameaux

ixemul a écrit :

C'est quand je vois des trucs comme ça que je suis bien content de faire du SQL à la main et du mapping avec Dapper

+1000
Mais je ne peux pas nier que sur de petites applications, les ORM comme EF ou NH peuvent grandement accélérer le travail (tant que l'on tombe pas sur un truc chelou comme mon cas...)

---------------
Away from keyboard, close to your breast

Yor_le_Bourrin

Houla si même à ce niveau ça plante, ça va être tendu. Je ne vois plus que :
- Ticket MS
- Sinon surcharger le générateur de requête pour qu'il prenne en charge ton Contains : https://docs.microsoft.com/en-us/ef [...] operations

J'avais déjà fait ça en EF6 pour intégrer des commandes FULL TEXT, mais ils ont enfin ajouté les DbCommandInterceptor en EF Core 3

BilupBaloo

Comme ça, moi je ne vois qu'un pb de cast que EF n'arrive pas à faire.

Ça plante sur tous les types ? Pour toutes les requêtes ?

Yor_le_Bourrin

Avec la dernière version ça n'est plus ambigu :
var bidules = (ids.Take(10) as IEnumerable<string> ).ToList<string>();
var objects = await _dbContext.Set<TEntity>().Where(r => bidules.Contains(r.id as string)).ToListAsync()

Là le constructeur de requête n'a plus d'excuse pour confondre la méthode...

BilupBaloo

ça n'est plus ambigu pour la liste mais le cast du champ est peut-être en cause (r.id as string) ?

Est-ce que cela fonctionne en spécifiant explicitement une TEntity ?

Message cité 1 fois

Publicité

Implosion du Sord

Fesseur de chameaux

BilupBaloo a écrit :

ça n'est plus ambigu pour la liste mais le cast du champ est peut-être en cause (r.id as string) ?

Est-ce que cela fonctionne en spécifiant explicitement une TEntity ?

En remplaçant (r.id as string) par (r.id.ToString()) le problème reste le même.
Le soucis doit être autour de ce cast pourtant... mais bon pour le moment je vais laisser mon évaluation client-side et attendre le retour d'un gars qui maitrise bien EF pour reprendre le sujet

---------------
Away from keyboard, close to your breast

Yor_le_Bourrin

Pas sûr que ToString soit supporté en EF Core, ni même le cast en fait. J'aurais tendance à faire "var idString = r.id as string;" avant, pour être sûr des types en effet.

C'est un peu pénible cette migration EF Core, pas mal d'acquis d'EF6 ont été perdus apparemment.

Message cité 1 fois

Implosion du Sord

Fesseur de chameaux

Yor_le_Bourrin a écrit :

Pas sûr que ToString soit supporté en EF Core, ni même le cast en fait. J'aurais tendance à faire "var idString = r.id as string;" avant, pour être sûr des types en effet.

ça n'apportera rien je pense puisque r.id est évalué côté serveur
mais je trouve ouf qu'un cast ne soit pas traduit... on bosse sur du SQL Server quand même derrière, c'est pas non plus exotique

Yor_le_Bourrin a écrit :

C'est un peu pénible cette migration EF Core, pas mal d'acquis d'EF6 ont été perdus apparemment.

vive Dapper !

---------------
Away from keyboard, close to your breast

TotalRecall

Ben dis donc c'est calme :sleep:
Tout le monde fait du .Net 5 à fond et n'a plus le temps de poster ? [:djmb]

Message cité 3 fois

---------------
Topic .Net - C# @ Prog

ixemul

Nan mais sans blague ! ⚡

TotalRecall a écrit :

Ben dis donc c'est calme :sleep:
Tout le monde fait du .Net 5 à fond et n'a plus le temps de poster ? [:djmb]

Nop... Core 3.1 encore ici

Yor_le_Bourrin

TotalRecall a écrit :

Ben dis donc c'est calme :sleep:
Tout le monde fait du .Net 5 à fond et n'a plus le temps de poster ? [:djmb]

.Net 5 n'est pas LTS, donc je reste aussi en 3.1. Surtout que les modifs ne semblaient pas si énormes. On verra l'an prochain quand il y aura la 6 (LTS).

Sinon je suis passé à Dapper pour un projet avec une base à gros besoin de perfs / requêtes ultra optimisées : je confirme que ça dépote. Apprentissage rapide et sans accroche, à part un léger sur le mapping des one to many. Merci au topic pour le feedback :jap:

ixemul

Nan mais sans blague ! ⚡

D'ailleurs, petite question Claims, Roles et authentification pour une WEP API .net core 3.1:

J'ai une appli ou j'ai des users, avec différents rôles, pouvant appartenir à différentes entités, il existe des trucs pour gérer ça ?

Exemple,

User1: User sur société A et Admin société B (les sociétés sont stockées en base et peuvent évoluer)
User2 : User sur société A et User sur société B
User3: Admin sur société A et Société B
User4 : User sur société A
User5: Super admin (Admin sur toutes les sociétés).

Le but étant de sécuriser une Web API (actuellement, un JWT Bearer uniquement pour les roles), il y a moyen d'ajouter la notion de "Societé" ?

Yor_le_Bourrin

Les policies et roles sont statiques (c'est des annotations quoi), donc tu ne pourras pas passer pas par ça pour gérer des variables (ie. les sociétés). Sauf bien sûr si tu as une API avec des routes par société, mais c'est donc du statique.

Ca te laisse la possibilité de renvoyer des 401 si mauvaise société dans tes méthodes.

Eventuellement tu pourrais faire un IAuthorizationFilter, mais faut que les paramètres de ton API soient suffisamment normalisés pour que tu puisses récupérer l'ID de ta société et le comparer à un Claim dédié dans ton token JWT

ixemul

Nan mais sans blague ! ⚡

C'est un peu le but de ma question,

Aujorud'hui, j'ai un token qui ressemble à ça :

Code :

{
"sub": "User1",
"email": "User1",
"DateCreated": "2020-11-26",
"jti": "8722208c-c3e1-42a1-891e-cb44a5c5f6b5",
"http://schemas.microsoft.com/ws/2008/06/identity/claims/role": [
"Admin",
"User"
],
"exp": 1606410960,
"iss": "Test.com",
"aud": "Test.com"
}

Et je voudrais mapper des ID devant chaque rôles du style :

Code :

{
"sub": "User1",
"email": "User1",
"DateCreated": "2020-11-26",
"jti": "8722208c-c3e1-42a1-891e-cb44a5c5f6b5",
"http://schemas.microsoft.com/ws/2008/06/identity/claims/role": [
"Admin:SocA",
"User:SocB,SocC"
],
"exp": 1606410960,
"iss": "Test.com",
"aud": "Test.com"
}

pour récupérer à la validation du token les droits du user pour chaque société.

En l'écrivant, je viens de me rendre compte que je pouvais peut-être faire ça dans les Events du JwtBearer :

Code :

options.Events = new JwtBearerEvents()
{
OnChallenge = c => { /* code pour splitter les rôles par société sur la request */}
}

Après.. est-ce que c'est propre... [:urd]

Yor_le_Bourrin

OK, je n'avais pas compris que ta question portait sur le token en lui-même. Pourquoi ne pas créer des claim JWT supplémentaire ?

Code :

{
"sub": "User1",
"email": "User1",
"DateCreated": "2020-11-26",
"jti": "8722208c-c3e1-42a1-891e-cb44a5c5f6b5",
"http://schemas.microsoft.com/ws/2008/06/identity/claims/role": [
"Admin:SocA"
],
"Societes": [
"SocB",
"SocC"
]
"exp": 1606410960,
"iss": "Test.com",
"aud": "Test.com"
}

Par la suite tu peux facilement te faire une policy ASP qui vérifiera tout ça. Par contre encore une fois ça m'étonnerait que tu puisses exploiter ça facilement, à moins d'avoir des controllers dédiés aux sociétés (genre /api/socA/product). Il te faudra passer par une des solutions que je donnais en dessus.

Edit mal compris la question, pas vu que tu avais des rôles par société. Avec ton premier json :

Code :

{
"sub": "User1",
"email": "User1",
"DateCreated": "2020-11-26",
"jti": "8722208c-c3e1-42a1-891e-cb44a5c5f6b5",
"http://schemas.microsoft.com/ws/2008/06/identity/claims/role": [
"Admin:SocA",
"User:SocB,SocC"
],
"exp": 1606410960,
"iss": "Test.com",
"aud": "Test.com"
}

Tu peux tout à fait exploiter de manière plus propre ce modèle, toujours via les policies ASP. ~~Les rôles sont de toute façon à présent déconseillés (mais pas deprecated) par MS il me semble.~~

Message édité par Yor_le_Bourrin le 27-11-2020 à 18:05:58

ixemul

Nan mais sans blague ! ⚡

Mouais... c'est finalement moins pratique que ce que j'avais envisagé de prime abord donc.. à savoir garder les rôles "classique" dans le Jwt et rajouter une couche Rôle/Société dans mon objet User chargé.

Avec vérification de l'opération sur la société avant le reste du code et levé d'exception si non autorisée (encapsulé dans un handler d'exception global).

C'est toujours relous les habilitations

Yor_le_Bourrin

Clairement pour moi dans ton cas le plus pratique reste l'exception + handler. Les claims JWT ne sont là que pour t'éviter de faire un appel DB en plus.

ixemul

Nan mais sans blague ! ⚡

Je vais rester sur ma solution alors

Sinon, tu sors ça d'où les rôles déconseillés par MS ? C'est remplacé par quoi ? ça m'intéresse, je pars sur un projet tout neuf et s'il y a un truc plus pérenne autant l'envisager tout de suite

Yor_le_Bourrin

Je pensais l'avoir lu, mais ça date de ASP.NET core 1. Je ne retrouve pas la ref sur le site, donc ça doit être faux :jap:

A titre perso je trouve que la nouvelle manière, les policies (https://docs.microsoft.com/en-us/as [...] etcore-5.0) sont plus adaptées au monde JWT que les rôles, vu que tu n'es plus limité à un claim (http://schemas.microsoft.com/ws/2008/06/identity/claims/role) mais que tu peux les combiner facilement.

Message cité 1 fois

ixemul

Nan mais sans blague ! ⚡

Yor_le_Bourrin a écrit :

Oui, j'ai déjà joué avec les policies sur d'autres projets, mais là, pas d'utilité directe (hors la problématique soulevée plus haut, mais qui ne m'avance pas plus )

Au pire, je peux toujours en rajouter "une couche" au besoin

Message cité 1 fois

overclocked

ixemul a écrit :

Pourquoi ne pas définir la société en tant que role ?

sur la doc ms https://docs.microsoft.com/en-us/as [...] etcore-5.0
If you apply multiple attributes then an accessing user must be a member of all the roles specified; the following sample requires that a user must be a member of both the PowerUser and ControlPanelUser role.

Edit: j'avais mal compris
peut être vaux mieux créer de new role, style adminsoca, adminsocb ...

Message cité 1 fois
Message édité par overclocked le 30-11-2020 à 00:39:01

ixemul

Nan mais sans blague ! ⚡

overclocked a écrit :

Ce n'est pas si simple, les "sociétés" ne sont pas figées (ce sont même des franchisés pour beaucoup, autant dire, il en arrive de nouveaux régulièrement, et certains ferment aussi).

De toute manière, je ne peux restreindre l'accès à une API sur le critères société, en effet, il suffit que le user soit admin d'au moins une pour pouvoir y accéder, je ne peux définir de prédicat sur la société qu'il consulte en "admin".

Le but est d'essayer de trouver une manière élégante de présenter les couples Rôles/Sociétés dans le JWT pour rester Stateless , mais finalement, on va se fader un state/renew token côté serveur pour vérifier les couples Rôles/Sociétés.

overclocked

Oui je vois pas d'autres choix, toute façon tu ne peux pas compter sur ce qu'il y a dans le token, le serveur refait pas un check ?

Implosion du Sord

Fesseur de chameaux

TotalRecall a écrit :

Ben dis donc c'est calme :sleep:
Tout le monde fait du .Net 5 à fond et n'a plus le temps de poster ? [:djmb]

J'ai passé une bonne partie de ma semaine à faire du portage de NuGet pour les rendre compatible .NET 5.0 !

---------------
Away from keyboard, close to your breast

ixemul

Nan mais sans blague ! ⚡

J'ai ma solution pour mon problème de gestion de droits évoqués précédemment !

Vive les policy et l'authorization handler !!!

Commençons par le resultat :

Code :

[HttpDelete]
[AuthRequirement("SupAdmin" )]
public async Task<Unit> Delete(DeleteGroupeCommandRequest command)
{
return await Mediator.Send(command);
}
[HttpGet]
[AuthRequirement("Admin","Grp",AuthRequirement.ResourceType.Request, "groupeId" )]
public async Task<ActionResult<GetGroupeCommandResponse>> Get([FromQuery] int groupeId )
{
var command = new GetGroupeCommandRequest() { GroupeId = groupeId };
return await Mediator.Send(command);
}

j'ai donc un attribut AuthRequirement qui permet de définir le role : "SupAdmin","Admin" ou "User", puis une Entite : "Grp","Soc","Etb" et enfin la description du champs de request que je veux "proteger".

Pour ce faire donc, on implémente un handler complet :

Code :

public class AuthRequirement : IAuthorizationRequirement
{
public enum ResourceType
{
None,
Request,
Body
}
public class RessourceProtect
{
public ResourceType ResourceType { get; set; }
public string Resource { get; set; }
}
public AuthRequirement(string role, string entite, RessourceProtect ressourceProtected)
{
Role = role;
Entite = entite;
RessourceProtected = ressourceProtected;
}
public string Role { get; set; }
public string Entite { get; set; }
public RessourceProtect RessourceProtected { get; set; }
}
public class AuthRequirementAttribute : AuthorizeAttribute
{
const string POLICY_PREFIX = "AuthRequirement";
public AuthRequirementAttribute(string role, string entite = "All", AuthRequirement.ResourceType ressourceTypeProtect = AuthRequirement.ResourceType.None, string ressourceNameProtect = null )
{
// Policy = $"{POLICY_PREFIX}§{role}§{entite}";
var policy = JsonSerializer.Serialize(new AuthRequirement(role, entite, new AuthRequirement.RessourceProtect() { ResourceType = ressourceTypeProtect, Resource = ressourceNameProtect }));
Policy = $"{POLICY_PREFIX}§{policy}";
}
}
public class AuthRequirementHandler : AuthorizationHandler<AuthRequirement>
{
public IMediator Mediator { get; private set; }
public IHttpContextAccessor HttpContextAccessor { get; private set; }
public AuthRequirementHandler(IMediator mediator, IHttpContextAccessor httpContextAccessor)
{
Mediator = mediator;
HttpContextAccessor = httpContextAccessor;
}
protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, AuthRequirement requirement)
{
var roleClaims = context.User.Claims.Where(c => c.Type == "Roles" ).FirstOrDefault().Value;
var userroles = JsonSerializer.Deserialize<UserRoleDto[]>(roleClaims);
if (userroles.Where(c => c.Role == "SupAdmin" ).FirstOrDefault() != null)
{
context.Succeed(requirement);
}
else
{
var requiredRoles = userroles.Where(r => r.Role == requirement.Role && r.Entite == requirement.Entite);
if (requirement.RessourceProtected.ResourceType == AuthRequirement.ResourceType.None && requiredRoles.FirstOrDefault() != null)
{
context.Succeed(requirement);
}
else if (requirement.RessourceProtected.ResourceType == AuthRequirement.ResourceType.Request)
{
var resValue = HttpContextAccessor.HttpContext.Request.Query[requirement.RessourceProtected.Resource];
if (requiredRoles.Where(r => r.EntiteId == resValue).FirstOrDefault() != null)
{
context.Succeed(requirement);
}
}
else if (requirement.RessourceProtected.ResourceType == AuthRequirement.ResourceType.Body)
{
// HttpContextAccessor.HttpContext.Request.Body.ReadAsync<object>();
HttpContextAccessor.HttpContext.Request.EnableBuffering();
var dataArray = HttpContextAccessor.HttpContext.Request.BodyReader.ReadAsync().Result;
var body = Encoding.UTF8.GetString(dataArray.Buffer.ToArray());
HttpContextAccessor.HttpContext.Request.Body.Position = 0;
var jsonReader = JsonReaderWriterFactory.CreateJsonReader(dataArray.Buffer.ToArray(), new System.Xml.XmlDictionaryReaderQuotas());
var root = XElement.Load(jsonReader);
var protectedRessource = root.XPathSelectElement($"//{requirement.RessourceProtected.Resource}" ).Value;
if (requiredRoles.Where(r => r.EntiteId == protectedRessource).FirstOrDefault() != null)
{
context.Succeed(requirement);
}
}
/* if (requiredRole != null)
{
context.Succeed(requirement);
}*/
}
return Task.CompletedTask;
}
}
public class AuthRequirementProvider : IAuthorizationPolicyProvider
{
const string POLICY_PREFIX = "AuthRequirement";
public DefaultAuthorizationPolicyProvider FallbackPolicyProvider { get; }
public AuthRequirementProvider(IOptions<AuthorizationOptions> options)
{
// ASP.NET Core only uses one authorization policy provider, so if the custom implementation
// doesn't handle all policies (including default policies, etc.) it should fall back to an
// alternate provider.
//
// In this sample, a default authorization policy provider (constructed with options from the
// dependency injection container) is used if this custom provider isn't able to handle a given
// policy name.
//
// If a custom policy provider is able to handle all expected policy names then, of course, this
// fallback pattern is unnecessary.
FallbackPolicyProvider = new DefaultAuthorizationPolicyProvider(options);
}
public Task<AuthorizationPolicy> GetDefaultPolicyAsync() => FallbackPolicyProvider.GetDefaultPolicyAsync();
public Task<AuthorizationPolicy> GetFallbackPolicyAsync() => FallbackPolicyProvider.GetFallbackPolicyAsync();
// Policies are looked up by string name, so expect 'parameters' (like age)
// to be embedded in the policy names. This is abstracted away from developers
// by the more strongly-typed attributes derived from AuthorizeAttribute
// (like [MinimumAgeAuthorize()] in this sample)
public Task<AuthorizationPolicy> GetPolicyAsync(string policyName)
{
if (policyName.StartsWith(POLICY_PREFIX, StringComparison.OrdinalIgnoreCase))
{
/*var role = policyName.Split('§')[1];
var entite = policyName.Split('§')[2];*/
var policy = new AuthorizationPolicyBuilder();
var policyString = policyName.Split('§')[1];
var policyObject = JsonSerializer.Deserialize<AuthRequirement>(policyString);
//policy.AddRequirements(new AuthRequirement(role, entite));
policy.AddRequirements(policyObject);
return Task.FromResult(policy.Build());
}
return Task.FromResult<AuthorizationPolicy>(null);
}
}

Bon, il y a encore un peu de code porky dedans, il faut que je gère les niveau Supadmin, admin et user avec un Enum Flag + Bitmask pour retirer des ifs, mais la mécanique est là !

:love:

Ha oui... .Net core, Autofac, MediatR et Automapper, c'est vraiment de la bonne came !!!

Message cité 1 fois

DiB91

Bwaaaaaaah

Coucou les copains

Parlant de .NET Core, je me suis enfin ( ) lancé sur un projet de site web en ASP .NET Core MVC.
Je suis encore pas mal dérouté pour le moment, je cherche encore mes contrôleurs, mes actions... mais bon ça va rentrer je m'inquiète pas.

Par contre un truc me gonfle profondément : je suis obligé de relancer tout le débogage quand je modifie un pauvre texte dans une vue ? :??:
Rien que changer le "welcome" dans Index.cshtml F5 et CTRL+F5 ne changent rien. Je suis obligé de redémarrer toute l'appli pour que ce soit pris en compte, c'est pas du tout pratique pour du web (je débogue avec MS EDGE, et le débogage de script est activé).
Y a un truc que j'ai pas compris ?

En ASP .NET MVC 5, avec les bundles c'était assez dingue de pouvoir modifier le CSS dans VS et la modif s'appliquait en temps réel dans mon navigateur :love:

EDIT : Ah, et il faut penser à installer le package de prise en charge (runtime) pour ASP .NET Core MVC 5.0 sur le serveur IIS

Message édité par DiB91 le 22-12-2020 à 12:00:28

---------------
Rehost | Collect | Link

Yor_le_Bourrin

@Ixemul : bien joué, c'est propre :jap: . Je vois qu'on a la même stack aussi (sauf autofac, l'IoC de base me suffit). Un petit swashbuckle pour la doc et tu as une API super clean.

Message cité 1 fois
Message édité par Yor_le_Bourrin le 22-12-2020 à 15:08:43

ixemul

Nan mais sans blague ! ⚡

Yor_le_Bourrin a écrit :

Pas obligé d'installer le package, tu peux aussi faire du standalone. Ton appli va grossir, mais pas forcément beaucoup vu que .net 5 va rajouter seulement les dépendances réellement utilisées. C'est d'ailleurs son gros atout par rapport à 3.1 de mon point de vue.

@Ixemul : bien joué, c'est propre :jap: . Je vois qu'on a la même stack aussi (sauf autofac, l'IoC de base me suffit). Un petit swashbuckle pour la doc et tu as une API super clean.

:jap:

Autofac c'est génial car ça rajoute de l'interceptor et des petits trucs sympas comme le propertiesAutoWired qui permette de faire une classe de base qui intercepte les injections sans avoir à se taper les constructeurs partout.

Je viens d'améliorer le concept en virant le ResourceType d'attribut, je récupère directement dans le context le type d'attribution de chaque paramètres sur le endpoint

Code :

((Endpoint)context.Resource).Metadata.GetMetadata<ControllerActionDescriptor>().Parameters[0].BindingInfo.BindingSource.DisplayName

ici pour le paramètre N°1 du array ça me renvoie directement Body ou Request en fonction de ma méthode de controleur.

Ha oui, je viens de virer le morceau bien porky à base de Xelement pour utiliser du JToken, c'est bien plus joli

Mes attributes deviennent donc :

Code :

[HttpPut]
[AuthRequirement("Admin", "Grp", "groupe.id" )]
public async Task<Unit> Update([FromBody]UpdateGroupeCommandRequest command)
{
return await Mediator.Send(command);
}

Avec un Json pour UpdateGroupeCommandRequest

Code :

"groupe": {
"id": 25,
"raisonSociale": "Raison sociale du groupe",
"actif": true
}
}

et pour un param request :

Code :

[HttpGet]
[AuthRequirement("Admin","Grp", "groupeId" )]
public async Task<ActionResult<GetGroupeCommandResponse>> Get([FromQuery] int groupeId )
{
var command = new GetGroupeCommandRequest() { GroupeId = groupeId };
return await Mediator.Send(command);
}

Le tout géré avec des flag Enum

Code :

[Flag]
public enum Roles
{
None = 0,
User = 1,
Admin = 16,
SupAdmin = 512
}
[Flag]
public enum Entites
{
None = 0,
Etb = 1,
Soc = 2,
Grp = 4
}

(j'ai gardé de la place entre user/ admin et admin/supadmin au cas où... )

Et j'ai évidemment un Swagger pour l'API

Message édité par ixemul le 22-12-2020 à 16:20:30

ixemul

Nan mais sans blague ! ⚡

C'est ma première archi hexagonale d'ailleurs... et la vache ! on en chie un peu à la mise en oeuvre, mais ça ouvre tellement de perspective pour après :love:

DiB91

Bwaaaaaaah

Allez, un petit crosstopic depuis le topic de Rehost

Y en a't-il par ici qui ont déjà eu affaire à la classe JavaScript Navigator.clipboard ?

J'aurai besoin de récupérer la Promise que ça me return via un appel Ajax vers mon contrôleur MVC.

Le but, c'est d'envoyer au serveur (pour enregistrement en BDD) le contenu (image) du presse papier... J'arrive à récupérer du text (via Navigator.clipboard.readText(), qui renvoie une chaine de caractère), mais pas d'objet "Promise" (via Navigator.clipboard.read()).
J'obtiens au mieux un Object dont je ne sais pas trop quoi faire de l'autre côté...

Une idée ?

Message cité 1 fois

---------------
Rehost | Collect | Link

ixemul

Nan mais sans blague ! ⚡

DiB91 a écrit :

Allez, un petit crosstopic depuis le topic de Rehost

Y en a't-il par ici qui ont déjà eu affaire à la classe JavaScript Navigator.clipboard ?

J'aurai besoin de récupérer la Promise que ça me return via un appel Ajax vers mon contrôleur MVC.

Le but, c'est d'envoyer au serveur (pour enregistrement en BDD) le contenu (image) du presse papier... J'arrive à récupérer du text (via Navigator.clipboard.readText(), qui renvoie une chaine de caractère), mais pas d'objet "Promise" (via Navigator.clipboard.read()).
J'obtiens au mieux un Object dont je ne sais pas trop quoi faire de l'autre côté...

Une idée ?

Si tu serialises cet objet, ça donne quoi ? ( binary serializer par exemple )

DiB91

Bwaaaaaaah

J'essaie ça dès ma prochaine session :love:
Je pensais qu'un appel AJAX était forcément sérialisé dès lors que j'imposais dataType : JSON :??:

Merci pour l'idée en tout cas, je regarde.

---------------
Rehost | Collect | Link

ixemul

Nan mais sans blague ! ⚡

Ou alors tu ne fais pas de read sur le blob...

un fiddle qui donne la démarche :

http://jsfiddle.net/bt7BU/225/

Pour le Promise, je vois pas... t'as un bout de code à montrer ?

DiB91

Bwaaaaaaah

Ouep, je fais quelques screens dès que possible.
J'ai à peu près le même algo que sur le fiddle, mais je ne sais pas comment renvoyer le blob côté serveur pour lancer l'upload / la sauvegarde en base

Message cité 1 fois

---------------
Rehost | Collect | Link

ixemul

Nan mais sans blague ! ⚡

DiB91 a écrit :

C'est pas le blob qu'il faut renvoyer, mais le target.result (URL... mais c'est une image encodée Base 64) du reader !

Côté serveur, tu prends en String (rien de graveleux hein ! )

Message cité 1 fois
Message édité par ixemul le 23-12-2020 à 15:12:12

Implosion du Sord

Fesseur de chameaux

ixemul a écrit :

J'ai ma solution pour mon problème de gestion de droits évoqués précédemment !

Vive les policy et l'authorization handler !!!

...

Ha oui... .Net core, Autofac, MediatR et Automapper, c'est vraiment de la bonne came !!!

Je travaille en ce moment sur un composant d’autorisation, je vais regarder attentivement ce que tu as fait, ça me donnera peut-être des idées

Message cité 1 fois

---------------
Away from keyboard, close to your breast

Publicité

Page : 1 2 3 4 5 .. 66 67 68 .. 77 78 79 80 81 82

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

C#/.NET managed

[Topic unique] .Net @ Prog

Sujets relatifs
service web REST en VB.NET HeySpread	Requete Access avec paramètres, éxécutée en VB .Net
impersonalisation sous ASP.NET	[Topic Unique] les blagues pourries de harko et florentg
Generation d'un GIF en ASP.NET	Appeler un service web .NET sécurisé en Java
Prog Visual Basic "periodicité"	[Oracle] Temps d'execution de requete tres long par rapport au .NET
[VB.NET] Lister des imprimantes réseaux	Fusion de résultats de requêtes dans une unique Table
Plus de sujets relatifs à : [Topic unique] .Net @ Prog

Page générée en 0.172 secondes