I am currently trying to implement Authentication using the RavenDB Authentication Bundle and the Facebook C# SDK in MVC 3. I have everything working to date except for persisting all of the information provided by the Facebook Graph API (such as the facebookId and the accesstoken).
One possible (albeit ugly) solution is to create a separate facebook document model for this information and manage both the AuthenticationUser and the facebook model when performing any actions against the user.
I was wondering, however, if there might be a more elegant way to handle this extra data and incorporate it into the AuthenticationUser document by possibly extending it somehow? Any suggestions would be greatly appreciated. Thanks in advance.
The easiest would be to inherit from AuthorizationUser and add anything you want.
You can also NOT inherit from it, as long it has has the same shape (expected properties match)
Related
I'm very new with those things, so I have some problems with understanding and figuring out which approach to use.
Currently, I am using .NET Core 3.1 and IdentityServer4 in my project. I am configuring my authorization server and there I have some controllers for creating users, clients etc.
In the controller for users handling I am using UserManager for all of the CRUD operations. Is that better approach than using dbContext?
I have created controller for handling clients as well. For this purpose, I am using ConfigurationDbContext, since I have not found some kind of a built-in manager for handling this.
Do you have some better solution? I am thinking of creating managers for this. Is there some example of that?
I want to create controllers which would function in the similar way, to have similar behavior, response results, validations etc.
Thank you for your help.
As far I as know UserManager comes with ASP.Net core Identity which is the way Microsoft gives built-in functionality to manage Manages users, passwords, profile data, roles, and others.
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-3.1&tabs=visual-studio
You can find Stores under IdentityServer4 namespaces like IClientStore and IResourceStore and more, so those interfaces have a similar Idea of userManager for users in Identity.
This is the source code https://github.com/IdentityServer/IdentityServer4/tree/master/src/Storage/src/Stores
Anyway there is an AdminUi that you can take a look to see if you find something helpful https://www.identityserver.com/documentation
I got a project assigned where we already have an up and running website and one of our clients wants to be able to track statistics from the website.
We want to make this available to all our clients as soon as we finish the development. Note that each 'client' have their own 'subdomain' to say so. Eg. www.website.com/client1 , www.website.com/client2 , etc. And we want to track the usage separately for each of these clients.
We will need to create statistics based on the usage of our own platform, pull in data registered by Google Analytics and also pull in data from a 3rd party which they will offer by an API of their own (they have a 3rd party solution that uses the data accessible via our API).
All this data needs to be shown on a webpage with graphs and tables.
I wanted to make sure we choose the right architecture from the start, in order to avoid scalability issues later on.
Started reading about Private and Public API's lately.
For now, we do not have another (internal) application yet that would use our own statisics, it would just be the website using it. But in order to be able to scale-up later if needed, and another application would like to use the statistics I think a private API would benefit us greatly.
In order to allow 3rd parties to use the statistical data we chose to let out, I was thinking of creating a Public API.
Is a Private&Public API the correct way to go about this?
One of the questions I am stuck with is how does the architecture for these API's look like. Mostly, right now we already have a public API regarding vacancy data. This 'API' is basically just a PHP class (controller) inside our CodeIgniter solution. It gets called via its URL and returns a JSON object with the results. (e.g. www.website.com/api/vacancy/xxx)
In order to create a (proper) private & public API solution/architecture. Should the API be set free from the website (CodeIgniter)? What are the common go-to solutions for this?
Or is it fine to keep it in our current platform the way it is now? (and people call the stats API via www.website.com/api/stats/xxx for example?)
It's almost always right to go with microservices like architecture so your initial thoughts sounds reasonable. Acting like this will give the possibility to scale and deploy your api independently and also will help you avoid performance side effects to your site (and vice versa). Pay attention how you access your main site data from within the new api if you don't want to finish with a monolith application.
Regarding the API i would suggest you to implement protocol like oauth2 in order to achieve the flexibility you (might) need. Also you can use swagger to document and test your API.
All i said might helps you a lot but first you have to answer yourself do you really need to go so deep or you just need a simple solution.
I think multitenancy is the best choice. Generally speaking, multitenancy is when every customer has own database. Data is separate. The codebase is same and already exists. As I understood the project is in progress status. You do not redesign and rewrite anything.
I have much experience developing for WordPress but this will be my first project developing for Shopify.
I will be customizing a 3rd-party Shopify Theme with custom functionality as per the client's website needs. I've been reading much documentation but I am still a bit confused about Shopify Apps...
My question is:
Do I need to build an App to extend the functionality of my theme, or can I just hard-code the new functionality directly into the theme? Is there any reason to develop an App for functionality that will only be used on my theme?
I thank you very much for your advice.
Do I need to build an App to extend the functionality of my theme, or can I just hard-code the new functionality directly into the theme?
Short answer: Yes. (Damn that mathematician's response!)
Is there any reason to develop an App for functionality that will only be used on my theme?
Longer answer: Sometimes, yes.
That wasn't very helpful
Longest answer: True. Let's break it down a little more, then.
Without knowing what you need to do, I can't offer a concrete yes-or-no answer to the question, "Should I build Feature X as an app?"
If you...
Need to add, modify or delete any objects that require admin privileges (including products, variants, collections, orders, etc.), or...
Need to listen for any of Shopify's webhooks, or...
Need to store data in an external database for any reason...
... you will need an app to have the permissions required to access and manipulate data at this level.
However, if you...
Can do everything you need with the existing Shopify objects, and...
Need few or no settings to control the desired behaviour...
... you would not need to create an app. Shopify themes have some powerful tricks & tools available to you, including:
The ability to create custom endpoints for any of the main types of objects to get the data you need;
Easily-edited settings_schema file to add arbitrary configuration variables to help control your mini-app;
Javascript endpoints to let you add, remove & edit products in the cart
Hopefully this quick breakdown helps you decide if you need to create an app or not. (And to anyone who does need to make a single-site app, remember that Shopify lets you create 'Private Apps' that don't have to go through the app store process to get widespread approval)
I thank you very much for your advice.
You're welcome! Hopefully it proves to be helpful. Good luck!
We are currently trying to figure out the best possible solution to integrate sylius with our ERP system through a REST api.
What would be the best approach for swapping out the ORM layer and implementing a cached API layer instead?
Many actions like product creation will be disabled since they are managed in a different system so we only need some write actions like (order and payment). All other read actions will go through either elastic search or the API.
Is override every manager and repository the way to go or is there a better solution?
Thanks
Is there a good extension for yii framework that controls user permissions. Give them different levels of access. I have checked some of them, they are good but up to date for example http://www.yiiframework.com/extension/rights/.
You can look up this Yii extension. I used it a couple of times myself. http://www.yiiframework.com/extension/srbac/
Before implementing an extention please checkout original rbac from yii. It is important to understand how it works. Extentions are mainly made to have an graphical administration for it.
http://www.yiiframework.com/doc/guide/1.1/en/topics.auth#role-based-access-control