Until today, I used UserManager's GeneratePasswordResetTokenAsync method to generate tokens. AFAIK, it is implemented by ASP.NET Identity.
But, I just found out about UserManager's SetNewPasswordResetCode method implemented by ABP.
I understand the differences between both. Why didn't ABP reimplement or use Identity's methods?
Also, which should I use?
Thanks in advance.
They are same. The reason why the ABP has duplicate this functionality is, at some time we needed to implement IUserTokenStore that's why reimplemented that method.
You can use ABP's method.
Related
A pretty specific query I know but one that hopefully applies more generally to the use of Autofac across the BotFramework SDK.
In the 'ContosoFlowers' sample, the DialogFactory class receives its 'scope' member, an Autofac IComponentContext, as its one constructor parameter.
However, I'm mystified as to where this comes from. I have an irrational hatred of DI anyway, but I still can't find some bootstrapper/service locator/module etc. that somehow links this to a concrete implementation. No obvious module. Is it baked in somewhere in the BotFramework code?
Also, can I ask what the purpose is of having all this DialogFactory.ContosoFlowersDialogFactory.Create() layer is? Say for example, when calling this.dialogFactory.Create<FlowerCategoriesDialog>()? This I assume is to avoid having to 'new' the dialog, and because the DI scope isn't available to the calling dialog? In that case, why have this factory injected into the RootDialog and not the IComponentContext scope itself?
Apologies if noob questions (very likely). Also please advise if there's a better place/forum for specific BotFramework samples code queries. Thanks!
Good questions! Let me try to address them:
IComponentContext. There is no registration/bootstrap of that interface. They are automatically provided by Autofac (see here).
ContosoFlowersDialogFactory. Your assumption is correct, the idea of having a dialog factory is to avoid having to 'new' dialogs manually, as that adds limitations around unit testing for example. Certainly, the approach you are suggesting is valid; and nothing prevents you to use the IComponentContext in the dialogs (please not that not only the RootDialog is using the factory, but also the other dialogs such as the SettingsDialog or the SavedAddressDialog). The reasons of having that layer could be subjective, so I would just provide you my point of view here. IMO, having these layers contribute to have a cleaner code and to avoid having DI's specific components across the application. In this scenario, the DialogFactory is the responsible of dealing with the DI layer, allowing you; to change the DI mechanism if you want; without having to update all the other components; or even in the case of a breaking change on Autofac; you will have just to deal with it in the factory. If I have to choose, I would prefer not having direct Autofac.* dependencies in my dialogs.
I'm new to Laravel & I wanted to know something about it's feature that calls Contracts.
(If my question not in place, let me know why, and don't just downvote it).
So from what I red in Laravel Documentation and say on Laracasts videos, I understood that contracts they are only interfaces for class implementation.
So what it's good for? That if I or someone else will implement those interfaces will all need to go by the interface and then I dont need to change my code at all?
Is that the reason why Laravel uses it's implementation as a contracts ?
Also I wanted to know, to achive the implementation I must bind the implementation to a contract?
Yes, I think your understanding is mostly correct. I will try to explain with an example. Let's say you have a PackageDeliveryServiceContract that has some methods like trackPackage, getShippingCost.
You create a FedexDeliveryService to adhere to the contract and implement those methods.
In your controller, you can just inject PackageDeliveryServiceContract and start using it right away. (are you familiar with laravel's dependency injection?).
Let's say later you decide you no longer want to ship with Fedex and use UPS instead. Then you can create UPSDeliveryService that also adheres to that contract.
Now, all you need to do is change your binding from FedexDeliveryService to UPSDeliveryService and you don't need to make any changes to your controller code.
Typically you will create the binding between contract and implementation inside a service provider such as app/Providers/AppServiceProvider.php
I have implemented OdataController(s) for my Web-API.
Is it possible to use a ChannelFactory (or WebChannelFactory) to communicate with the Web-API, specifically i would like to call custom Functions and/or Actions.
Of course, the OdataController i have created does implement a ServiceContract.
But i am not sure if this is possible because of the url/namespace.
So the answer is a resounding YES. I just implemented the service contract and set up Routing to make the service operations work.
currently I am trying to register a Doctrine-Eventlistener for every request in my FLOW3-Package. Some research pointed me to the Package.php, but unfortunately the ObjectManager is not available when the boot()-Method is called.
I searched the whole FLOW3-Documentation http://flow3.typo3.org/documentation/guide/partiii/bootstrapping.html without luck
Any hints on which is the right place to do package-wide setup with access to the object manager?
thanks and best regards
Your are bit to early in the bootstrap to get every object, I have a problem, maybe related to yours, you can check my bug report on http://forge.typo3.org/issues/33838
Why do you need a Doctrine Eventlistener, maybe you can use AOP to have this kind of feature ?
What is the best approach to version WebAPIs?
I am building an API from scratch and I would like to ensure that it will version gracefully in the future. I am envisioning something like mysite.com/api/v2/...
One approach I see is to create a separate project (web app) for each version of API. But perhaps there are better ways to do it?
Thank you for your ideas.
Including version number in the URL is the standard approach as I explained in this post (I do not repeat the content): Implementing versioning a RESTful API with WCF or ASP.Net Web Api
You do not need to create a completely new project although you can. The problem that you will be facing with a single project is that there will be collision of names:
/api/v1.0/Car/123
and
/api/v2.0/Car/123
both will point to CarController while you can have only one of those. The solution would be to implement your own IHttpControllerSelector and register with the DependencyResolver. This implementation will look at the version number and perhaps find the type based on the namespace.
UPDATE
I do not intend to start a REST controversy here. But as #DarrelMiller points out, here is an older discussion on the same subject discouraging my suggested approach:
How to version REST URIs
I personally think URL versioning is the way to go.
You will need to create your own implementation of IHttpControllerSelector. The best way is to base this implementation on Microsoft's IHttpControllerSelector. Then you can decide in your IHttpControllerSelectorif you want to version by URL or by content-type.
The most basic implementation directly implements IHttpControllerSelector and just implements the SelectController method but performance reasons it is better to implement some caching around it.
For finding the Controller you simple the IHttpControllerTypeResolver instance you can get using HttpConfiguration.Services.
I've used something like this: http://damsteen.nl/blog/implementing-versioning-in-asp.net-web-api. Also put some code on Github: https://github.com/Sebazzz/SDammann.WebApi.Versioning.