I have a WSS 3.0 site with FBA and a custom user management web part. To track user email address, I have been using the Email property of the MembershipUser object. I just realized today that if you go into People and Groups and look at the email address for a user, the email address is blank, and can be edited there independent of the MembershipUser value. It seems that the alerts system uses the email address that is stored in People and Groups.
I have not gotten into recoding yet because I want to make sure I'm not missing anything first. I assume I could switch from MembershipUser.Email and story my information in SPUser.Email instead. But I seem to remember that on a different project I used MembershipUser.Email with no problems and the alerts went out fine (although that was MOSS).
So I guess I have two questions:
Is there a way to tell People and Groups or the Alerts system to use MembershipUser.Email?
Is it best practice to use SPUser.Email for email storage, rather than MembershipUser.Email?
This post goes in-depth in getting SharePoint to sync the user profiles in your FBA store by naming all properties sharepoint should know about in the web.config and create those properties in your ProfileProvider. Not sure if it is what you are looking for exactly though. FBA user profile mapping does not work as clean as AD user profile mapping does out of the box.
Also, check out the User Profile Import Tool on CodePlex. It's for MOSS but might provide some pointers.
Related
Running into a bit of an odd issue. I assume it may be a setting somewhere?
Using the API integration for embedded forms. We have two brands, so I've made two users with the same roles. Their job is to be the sender for any embedded form for their respective brand. Their roles are both set as sender from the user settings tab.
support#brand.com
support#other-brand.com
Each user is in 2 groups, developers and their respective brand. Simply being part of developers will allow them to be assigned as the sender of any API templates. It's worth noting, these two users are identical to one another in setup, only difference being support email.
Using user 1, there are no issues, and everything works as intended. Using user 2 however, I get the error "consent required" when trying to get a JWT token?
I've gone through all and any settings I could find, but nothing seems to do what I need. Both users belong to the organization, so I'm simple confused.
Any help and direction is much appreciated.
The answer was I needed to claim the #brand URL the 2nd user was under, which had not been claimed via the application admin interface.
Consent is per user, you would need the second user to log in and navigate to the URL For consent.
If you are using the developer/sandbox/demo environment (not production) the URL you would want to set looks like this:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=<your IK>&redirect_uri=<some URL you defined for the IK>
Remember to define the redirect_uri in the Apps and Keys page in the settings page where you created the Integraiton Key and you should be good.
My SharePoint Environment is SharePoint 2019 On Premise
Is it possible to show alert message on the page or popup window, when user SHARE the document on the Document Library.
When we Share the document, whether or not we could modify the mail alert template/ Content.
Thanks
By 'share', I assume you mean you want to show a message anytime someone edits the permissions of a document. (Since technically, I could 'share' a document by emailing someone the link to it.)
To my knowledge, the only way to achieve this would be to build a custom-code (SPFx) solution which uses API's to interact with the document's permissions granted via app-only access. And block users' ability to access those documents in the traditional way through SharePoint. This would give you full control over the UI, and prevent users from granting access (sharing) elsewhere.
Another option you might investigate is Azure Rights Management. Sensitivity labels applied to documents/libraries can be configured to automatically display headers, footers, watermarks, and even encryption when they are accessed. Exchange can also be configured to display a 'tip', when it detects users are trying to email a sensitive document. Full disclosure: I have only worked with these features in SharePoint online and I'm not certain of their capability in an on-premise environment.
We have a SharePoint 2010 extranet web application that uses claims authentication.
The Intranet zone is using mixed authentication (NTLM against internal AD and FBA against a separate AD).
The Extranet zone uses FBA only against the separate AD.
We have sites that have NTLM users in the Members SharePoint group. We have librarys with "Person" colums limited to the Members group. We would like to allow FBA users to pick NTLM users that are in the Members group when fillng in item metadata. The problem is that the FBA users can see the NTLM users in the people picker but when they select them, the user is not resolved. I realize we could probably work around this by adding NTLM to the Extranet zone but prefer not to do this if possible.
My questions are:
Is this a scenario where a custom claims provider would be appropriate?
Is this a problem that could be resolved with the peoplepicker-searchadforests property? (I've not been able to get my head around a real world example where this property is in play)
This is how I understood that the people picker works. I'm not 100% sure so don't take it for absolute truth :)
Basically, in the context of the Extranet application, all standard pickers are completely unaware that the internal AD exists. The "hits" you get in the people picker are found in SiteUsers list and/or profile database.
"Is this a problem that could be resolved with the peoplepicker-searchadforests property?"
I don't think so, I think that even if you are able to make the people picker search other ADs might give some pretty weird results, like being able to add a persons permission to some object, but with the FBA claim prefix, which does not equal the user when logged in using NTLM. (A user signed in with NTLM and Claims is technically different users.)
"Is this a scenario where a custom claims provider would be appropriate?"
I don't think so :(
One trick that you can do for people picker that YOU create (i.e. you have a custom page or webpart or something with a people picker), there are several properties you can set to change from where the users are retrieved. For example you can set a property like "WebApplication" or similar that basically make the picker work as if in the context of the internal application despite the current user being logged in on the external app.
What I'm thinking is maybe there is some way to enable the NTLM membership provider on the extranet application, but without actually enabling end user authentication with it. It doesn't sound impossible but I'm not sure exactly how that would be done though.
I have a code activity that sends an email in a VS workflow. It simply sets the 'To' property to the name of a SharePoint group in the site collection. However, only the 1st person in the group gets emailed.
Any ideas why this is happening?
thanks
Does your group contain anything other than just users (ex: distribution lists, ad groups)?
If this is still a problem and you need to be able to send to a SharePoint group, I would recommend writing a custom workflow Action that would gather the emails of all the users in a specified group (you can find many tutorials online on how to make a custom action).
Turned out it was not even emailing the first user. I decided to extract the user emails programatically instead. Works fine.
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.