Suppose that we have difference SMS provider for each tenant (each tenant have their own SMS provider that wants to send SMS thorough those provider) How can we implement this situation in ASPNetBoilerplate?
If each tenant has only one sms provider then you can create a complex type on Tenant class. If each tenant has more than one sms provider then create TenantSmsProvider entity.
I did not understand why you want to create DLL!
I suppose you are asking for the Dependency Injection.
You should create a factory (say ISmsProviderFactory) that creates sms provider (say ISmsProvider) by tenant id (say GetProviderByTenantId(int tenantId). This is a common software pattern. Then you can inject ISmsProviderFactory and get ISmsProviderFactory based on a tenant whenever you need.
Instead of creating a custom factory class, you can use Castle Windsor's API to register dependencies by factory. Thus you can directly inject ISmsProvider in your code.
Now, the problem is how to implement SmsProviderFactory? There are different approaches depends on your requirement. But this part is out of scope of ABP and you can find many articles on the web.
BTW, if you want to take advantage of ABP's plugin system, then you can design it a bit different: Every plugin dll can add an ISmsProvider to a dictionary (where the key of dictionary is tenant id / name) so your factory can pick registered provider for given tenant.
Related
I had to create additional table in tenant user store to store some specific data. Now I need to fetch data from this table during authentication in authenticator. What possibilities do I have to make a sql query to this new table? I know I can create custom user store manager, but it looks like overengineering to me.
There are two ways that you can do this.
Write a custom authenticator
Write a custom user store manager
The above depends on the logic that you want to implement.
== Write a custom authenticator ==
Let's say you need to use these for username and password authentication. Then you can implement a custom authenticator by extending the existing authenticator. You can refer to this blog for more details.
== Writing a custom user store manager ==
You can easily extend the existing user store manager and overwrite the auth-related methods to suit your need. You will be able to find many documentation and medium articles related to this. I would like to recommend this approach since this is related to the user stores.
Also, you can see whether you can achieve this using the Pre-Post listeners (If possible then this would be the easiest approach). During the user store manager auth methods, UMs fire pre-authentication and post-authentication methods. If you add a new listener and subscribe that to any of those events you might be able to achieve this use case.
I'm using Django Rest Framework and it's integrated with an external service. I'm using an endpoint to receive a callback from a webhook whenever a new task is created in the external service.
When the callback request comes in, my code needs to create at least one object. But it's possible that multiple objects will need to be created from multiple different models. For example, if a new task is created it's possible that it was created by a new user, in which I also need to create a new user object to reflect this.
In total, there could be up to 5 additional objects made as side effects. I'm aware of multiple different places that this logic could be added (e.g. service layers, serializers, models, managers, views). But there seem to be issues with all of these.
Has anyone dealt with this issue before? If so, how did you solve it?
First of all, it is important to understand the difference between an RPC-style API and a RESTful API. Simply put, you can imagine an RPC API to be "methods" that are "actions", while a RESTful API represents the state of your models.
For example, let's say we want to create an endpoint to handle user registration.
A RPC style endpoint might be /api/register. A register function that might do X number of things.
A REST style endpoint might be /api/users. Not an action, but simply just an endpoint that give us the state of the users that exist. A GET request would list the users and a POST request would create a new user.
With that said, it might be a bit more clear that in general, creating endpoints that do X number of actions might not be very "restful", and using a framework specifically named "Django REST Framework" might not be the right choice.
So in your particular case. I suggest that you avoid creating endpoints that work as methods, and instead treat them as the resources that they represent. This means that if you need to create a new user, you do a request to the user-endpoint, then if you need to create a new article with that user, you do a second request to the article-endpoint.
Using Signals for Side Effects
I think if you do want side effects, they should be managed using signals. For example, let's say that you want to send out emails using a contact form. Instead of having a /api/send_email endpoint, you instead do a /api/messages/ endpoint that represent a Message model, and then you use signals to send out emails whenever a new message is created.
By doing things this way, it still means that the API endpoint itself just represent the state of the model, while the side effect of modifying the state (sending a message on creation of a new message) is moved to the signal's responsibility.
I'm using WSO2 Identity Server 5.3.0 and several LDAP user stores.
I need to integrate AWS as a service provider and WSO2 IS as identity provider.
The situation is: I have lots of users stored in the user stores and some of them have specific roles that should be allowed to login to AWS service. So far I don't have the possibility to alter / update the current user stores.
That's why I'm trying to figure out a way to populate / generate / translate / calculate the value of a claim based on an already stored attribute in the user store.
I have a sort of table with the groups coming from LDAP's memberOf attribute a user could belong to and their equivalences to AWS attributes that should be stored in specific claims in order for AWS to allow that user to enter certain services.
The end user is willing to solve this situation within the WSO2 IS component without altering the stores content.
I'm wondering if the only way to do this is writing a custom User Store Manager or a Custom Claim Handler [1] to deal with this particular situation or there is a more standard way to accomplish this.
I will appreciate any input, thanks in advance
[1] http://pushpalankajaya.blogspot.ca/2014/07/adding-custom-claims-to-saml-response.html
I think Claim Handler is the right place to implement your logic. You can find a sample in https://github.com/mefarazath/CustomClaimHandler
I'm building a nutrition skill and I want to include some calculators. I could have Alexa ask for the parameters each time something is calculated, but I'd prefer to have users set up a basic profile for themselves to store age, height, and weight values.
I found a small section of Amazon's documentation that talks about how the userId element could be used to store attributes across sessions. Will that work for what I'm talking about though? Or will I have to add OAuth?
There are two way to do this:
1) You can use sessions.
In this method, your data will be vanish when session is end (user stop talking with your skill)
more details https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/alexa-skills-kit-interface-reference#session-object
2) You should implement an oauth 2.0 server to store user data. It is not that easy but you can find some oauth server example in here https://oauth.net/code/
For connecting your skill to your oauth server, you can follow here
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system
bonus: If you do not want to implement an oauth server, you can use Login with Amazon (or login with google) services. But you will still need a database server to store data
The userId that you get on your requests uniquely identifies an Amazon account, not a person. Despite the option to switch between different accounts on a single device (see: https://www.amazon.com/gp/help/customer/display.html?nodeId=201628040), the feature to identify people has been discussed (http://time.com/4683981/amazon-echo-voice-id-feature-2017/) but it's not available yet.
As already mentioned in the comments, you will need to persist the session information between sessions and you could use the userId to identify each account.
But in any case, you don't need account linking or using Oauth to simply identify a person.
Additionally, I'd recommend you to stay within the Amazon ecosystem and run your stuff in Lambda (with free tier and with development credits for developers publishing Alexa skills).
If you need help getting started, I have a single-file template for Alexa skills using Python and several examples:
https://github.com/josepvalls/ask.py
I have a two repositories Catalog and User, I have a situation where I need to call a method within the catalog repo from the user repo, is this good practice or is there a better way?
You shouldn't be handling those kind of authorization checks within your Repositories. A business rule like "This user requires X comments to post" isn't really a repository query, it's a property of your User.
Also, authorization calls are made very frequently in an application, and you really don't want to hit your database every time a check is required.
You should properly load these permissions into your User object which is then cached for the current request, and use your domain:
public class Service {
public void Save(Post post)
{
if(User.GetCurrentUser().HasEnoughCommentsToPost())
postRepository.Add(post);
}
}
I would reference the other Repository at the upper layer, such as a service layer
I think that in your case authorization is part of your domain logic. So I'd create an abstract class or interface called AuthorizationPolicy (maybe you can find a better name closer to your domain), in my domain layer. Before you call a method on the repository, the client should check if the have have permission based on the policy.
Another solution, because the interface of a repository is also part of the business logic, you can create a base class for your repository which check permissions of the user and delegate the rest to derived classes.
The implementation of the AuthorizationPolicy will talk to the Catalog class if you want. This way the two repositories are well decoupled.