Developer forum

Hi Anders,

If I am not mistaken, you can already do that with a bit of tweaking on the Recovery Password Template.

See my dump.

Thank you,
Adrian

Thanks for quick reply, Adrian.

That is right, but we are using the mail address for the username, which cannot be deselected (I think?!)

It is true I have not tried that.

But even so, the system will look for the user having the email address that is entered in that field and a specific value in some custom field that you want to use.

I have had similar setup in some projects and I could use this functionality.

Adrian

Hi Anders

Adrians solution should work.

We also have the feature "Include shop id in extranet log in" that can be activated in settings for users. That means that when logging in, the shopid from the current context is included to tell 2 users with same username apart. See dump 1. By enabling that feature, and giving the user a value in the field accesusershopid in the database, you can handle 2 different logins. Just added TFS#46670 that will also enable this feature for recover password from the layouttemplate (as opposed from Adrians solution that is tied to users app).

Using the new feature you can do like this:

<input type=text name=username value="user@domain.com">
<input type=hidden name=shopid value="shop1">

<input type=text name=username value="user@domain.com">
<input type=hidden name=shopid value="shop2">

and have 2 different accounts resetted.

See dump #2 for new field that will also appear on the user if that checkbox is enabled.

Out with next 8.4 hotfix

Hi Nicolai,

Yes, I am aware of that feature, but the problem exists when we do not have shops but just regular websites.

Best regards, Anders

So - what? Adrians solution should do it, right - using an extra field?

I do not know how to guess the right user without data...

Hi,

I tried the above information to include the ShopID when creating a new user to allow the registration into 2 different websites of the same solution. According the manual, I checked the option "Include shop id in extranet log in", verified the default shop in the Ecommerce settings and the Multishop Advanced module, and added a new line in the "CreateAccount.cshtml" template to set the ShopID:

            <input type="hidden" name="ShopID" value="SHOP1">

 I guess this line is not working, because the created user has an empty value in his "Shop ID" data. I also tried typing the line with name="UserManagement_Form_ShopID" but no success.

Any clue about what can be wrong?

Regards,
Tomas

Thanks Vladimir for the prompt response :-)

Where can I track the TFS#66047 to know when is solved? I don't see it in the Known bugs page

BR, Tomas

Ok Nicolai, thanks for the info!

I updated the Dynamicweb.Security to 8.1.3 and modified the "CreateAccount.cshtml" with the line:

            <input type="hidden" name="UserManagement_Form_ShopID" value="SHOP1">

The new user is created and the ShopID is stored.... but the new user cannot login! 

I guess there is a bug in the new library, as everything is ok when I remove the above line of template.

BR,
Tomas

You have to ensure that the login box then resides on a website where the shop with ID SHOP1 is chosen on the website settings, ecommerce dialog.

Oooops! I actually did it with that purpose, to forbid the login, hahaha

I forgot to change the "SHOP1" testing parameter with the real ShopID. It works great.

Thanks for the help!

Hi guys,

The ShopID is a very good differentiator but it still does not solve Anders's problem.

I just realized now that we are facing the same issue in one of our projects.

We have 2 websites, on different languages with different URL's and just one shop.

The ShopID does not do the trick. We probably need something similar based on AreaID.
I realize this feature will not get implemented overnight. In the meantime (assuming you will consider it as a valid request) we need a workaround. A notification maybe? Or another Ninja trick from Sensei Nicolai?

Thank you,
Adrian

Hi Adrian

I think the right approach is to be able to configure login operations based on groups - maybe "Login groups" so we can control singularity of usernames per login group. Of course this is a bigger change that will require some implementation and test from our side.

In the meantime, my best ninja trick would be to use the SHOPID field on the user and set a random value to it so multiple users can be created with same username. Also create a custom field with the areaid or whatever you want to vary by.
Then create a Notifications.Standard.User.OnBeforeExtranetLogin notification subscriber that will grab the username when a login begins, see if there is something else in request.post - i.e. AreadID=123 or custom key, and then do a nasty update on the userdatabase that will set the AccessUserShopID to the current websites SHOPID for the user that you want to login - using your custom field. I.e. something like this

• UPDATE user SET AccessUserShopID = "BLABLA" WHERE UserUserName = 'UserNameLoggingIn' 
• UPDATE user SET AccessUserShopID = "SHOP1" WHERE CustomField = "CustomValueFromQuerystring"

And then clean up in the Notifications.Standard.User.OnAfterLogin or error notifications.

Totally hacky - and myabe need a little trial and error to get right.

BR Nicolai

Hi Nicolai,

I agree. Controlling the access based on UserGroups makes a lot of sense and I also understand it is a big change.
That's why I suggested AreaId. I was hoping it might be easier :)

We'll try your Ninja trick in the meantime. We already started on the OnBeforeExtranetLogin  notification subscriber. We'll see where we get to it.

Thank you very much,
Adrian

Hi

We are using the "include shop id in extranet log in" feature as described in this thread, and in the documentation in order to seperate users between multiple sites. We have enabled the setting, setup the default shop in the website settings as described, and placed a hidden input into the appropriate user management form (create profile, login, forgotten password) i.e.   

We are having the following issues,

1. The fogotten password mechanism (using the recovery link action) is still sending out password reset links to all users with the same email address. This email field is the only field selected in the Fields for password recovery on the app. The ShopId field does not show in this list. Our work around is to maintain a seperate custom user field with the shop id populated which we can select in the Fields for recovery and post as a hidden field when requesting a recovery link. 

2. We would like to enforce unique email address/usernames within each site. However when selecting the Require unique email setting for the app on the registration page the uniqueness validation does not take into account the ShopId. Again we have implemented a work around by doing the email/username validation in a UserValidated Notification Subscriber, but would like feedback on anything we are missing. Note that when creating a user from the backend the uniqueness validation does take into account the ShopId.

3. We are using User and group types to seperate custom user fields between sites and would like to include the ShopId in the field definitions but it does not appear in the list.

Note we are using Dyncamic Web 9.7.1

Thanks

Hi Steve

Nice job on setting that up and bypassing the issues 1+2! I have send this to our QA for verification - we should get back an explanation or bug fixes.

I am not sure I understand your question 3 - could you ellaborate?

Thanks, Nicolai

Hi Nicolai

We are running multiple websites in a single instance of Dynamic Web and each website has a different type of user, each with specific custom fields. We are using the User and Group type feature so that when viewing the user from the admin stite only the appropriate fields for that user are displayed. We were hoping to include the AccessUserShopId as a readonly field in the user type definition so that we could verify it has been set correctly but it doesnt appear in the list of available fields. This is not really a big issue as it was more for debugging than anything but was including it incase it was related to the first two issues.

Thanks for the quick feedback, 

Steve

Hi,

New TFS 70377/70371 have been submitted to fix/implement issues against points 1-2, will be provided in an upcoming release. Thanks.

BR, Oleg QA

Hi Steve

The TFS 70371 point 2 has been released in Dynamicweb hotfix version 9.7.4 (Feature TFS 70377 is planned for later release)

To upgrade please choose this version from download:

http://doc.dynamicweb.com/releases-and-downloads/releases

Let me know if you need any more help regarding this

Kind Regards
Dynamicweb Support
Kristian Kirkholt

Hi guys,

Any news on the TFS 70377?

BR, Mario

It was added to next sprint yesterday (starts Wednesday) and planned for 9.8.1