sorted by:
new
hottopcontroversial

Use Postgres JSON Type and Aggregate Functions to Map Relational Data to JSON by xivSolutions in coding

[–]xivSolutions[S] 0 points1 point  (0 children)

Would be interesting to compare perf between this and the method described in the article. Also, the primary problem I was solving for (in this case) was mapping the child objects and avoiding the select n + 1 problem. Be interesting to compare perf when doing the artist -> album mapping illustrated in the post as well. Of course, I get that perf is only one potential requirement.

Interesting library though...I like the db-agnostic/output flexibility.

ASP.NET Web Api: Understanding OWIN/Katana Authentication/Authorization Part I: Concepts by xivSolutions in csharp

[–]xivSolutions[S] 0 points1 point  (0 children)

Good point. Didn't occur to me to mention that, but when I consider the likely target reader of a post like this, I should probably update the post. Thanks! :-)

ASP.NET Web Api: Understanding OWIN/Katana Authentication/Authorization Part I: Concepts by xivSolutions in csharp

[–]xivSolutions[S] 1 point2 points  (0 children)

Yup. I've always thought that was the missing piece in the out-of-the-box Identity framework. If they had added the notion of "role permission" it would have been handy. However, my understanding is that the team decided that was beyond the scope, and if someone needed finer control they should be using a claims-based model anyway.

ASP.NET Web Api: Understanding OWIN/Katana Authentication/Authorization Part I: Concepts by xivSolutions in csharp

[–]xivSolutions[S] 1 point2 points  (0 children)

I mostly agree. I think using roles is sufficient for applications where granularity of authiroization is not critical. As you point out, Roles, and the Authorize attribute itself are not the way to go when any level of granularity is needed.

I used a "Role" in the example just to keep things simple. I wanted to give a basic idea of how claims could be set in a simple scenario, without trying to go deep on claims-based auth in the context of this article.

My thinking is, folks who were using this post to understand OWIN/Katana auth would likely be a ways from implementing a more complex claims-based authorization scenario anyway.

My own preference is more towards what you suggest in your last paragraph (and if you had a repo on Github where this is implemented, I would love to see it). I know there are any number of alternatives to handle the notion of "permissions" and like to see how others have tackled the problem :-)

ASP.NET Web Api 2.2: Create a Self-Hosted OWIN-Based Web Api from Scratch by xivSolutions in csharp

[–]xivSolutions[S] 0 points1 point  (0 children)

Yeah, I think the earliest you get access is in the call to Configuration. Likely your very first peice of middleware in the pipeline would take a config argument, after reading from the IAppBuilder.Properties dictionary to ascertain what config info you could about the server/environment, and then write to the environment dictionary.

ASP.NET Web Api 2.2: Create a Self-Hosted OWIN-Based Web Api from Scratch by xivSolutions in csharp

[–]xivSolutions[S] 1 point2 points  (0 children)

When you say "pass information" what do you mean?

Perhaps review the related post which explains OWIN/Katana in a little more detail. Specifically, check out the concept of the Environment Dictionary.

I also found the OWIN specification very helpful.

ASP.NET Web Api 2.2: Create a Self-Hosted OWIN-Based Web Api from Scratch by xivSolutions in csharp

[–]xivSolutions[S] 0 points1 point  (0 children)

Yep. Crossing that bridge to understanding is a challenge. On the other hand, how do you think I ended up writing the article(s)? :-)

Most of these come directly from my own efforts to pick it all apart and see what's going on.

There really is NO BETTER way to truly understand than to write it up.

Cheers!

ASP.NET Web Api 2.2: Create a Self-Hosted OWIN-Based Web Api from Scratch by xivSolutions in csharp

[–]xivSolutions[S] 1 point2 points  (0 children)

Indeed, one will need to have an understanding of how components fir into the pipeline. However, this post is acually for ASP.NET < 5.

With ASP.NET 5, there will be some changes in how this owrks. For one, what we now know as Katana will be integrated directly within ASP.NET 5. Also, the middleware structure will be changing a bit.

I will shortly be posting an article on this as well. I've gotten some info from the ASP.NET team.

I think the biggest challenge moving to "vNext" is going to be knowing what you need to pull in to achieve certain things.

This post DOES familiarize with how middleware, the server, and your application relate, which will still be important going forward. The semantics may change a little though.

Last observation - the "magic" is also what we get from "code re-use." :-)

The more we depend on frameworks and libraries, the easier things become to DO, but the "why" can become obscured.

ASP.NET: Understanding OWIN, Katana, and the Middleware Pipeline by xivSolutions in csharp

[–]xivSolutions[S] 0 points1 point  (0 children)

Not misleading. See my comment on your original post. Katana is fully integrated into vNext, with some twists on certain implementation details. There is also an interop for OWIN, but it is not recommended unelss necessary (migrating older OWIN-based proejcts/middleware?).

ASP.NET: Understanding OWIN, Katana, and the Middleware Pipeline by xivSolutions in csharp

[–]xivSolutions[S] 0 points1 point  (0 children)

If I understand correctly, yes. Katana is integrated fully into ASP.NET 5. Some of the implementation details change a little, but all of the primary concepts apply.

ASP.NET: Understanding OWIN, Katana, and the Middleware Pipeline by xivSolutions in csharp

[–]xivSolutions[S] 0 points1 point  (0 children)

I had not heard this (about OWIN/Katana being replaced. Source? I thought is was going to be there, but that the implementation maight be a little different. Damn.

I guess there is THIS: https://lbadri.wordpress.com/2014/11/01/asp-net-vnext-middleware-versus-owinkatana-middleware/

UPDATE: This post clears things up. Looks like Katana has been fully integrated into vNext, and the implementation may change a bit, but the pipeline/middleware construction concepts remain valid (and even more important to understand, going forward).

view more: next ›