The biggest problem I have faced so far in sharepoint, is to be able to make a certain webparts invisible or hide if the user is not logged in, basically to be able to make an audience for anonymous user.
If anyone knows how to do that, please help.
As far as I know the only way to do that out of the box is to wrap the complete Web Part Zone in a SPSecurityTrimmedControl.
Another thing you could try is to create Control Adapter for every single Web Part type and then implement the display logic in there. Please notice though, that this approach has some limitations. The most important is that all Control Adapters will be applied to every single Web Part in the given Web Application of the given type.
A little trick I use is to hide the web part in your CSS (either your master CSS or another web part), and then use ANOTHER web part - this time targeted to authenticated users - that overrides the initial CSS, making the content visible. I wouldn't recommend it for secure content, since the web part is still being rendered at the client, but if you're going for UI elements, this works perfectly.
Related
I am trying to create a dashboard via SharePoint and I would like to create a section beneath a displayed document where users can type and submit a description of what is going on in the document above. I don't want the users to be able to edit the site page in order to add text to the page so I believe the best solution would be the creation of a web part where a user can create and submit their desired description. The only web parts that I've come across to do something like this are the Note Board web part and the Microfeed web part. The Microfeed part seems too much like a social media page. My problem is I would like to try the Note Board web part but whenever I insert it on the page it never displays an area to type in, just the title "Note Board".
So it seems that this problem came up because of the way my account is related to this particular SharePoint site that I am editing. My account doesn't have a profile attached to it essentially and the way that these notes are shared and stored directly relates to having one of these profiles. The Note Board Web Part turned out to be working perfectly fine my account is just not capable of posting within it. (I figured I'd answer incase anyone else comes up with this problem.)
I am currently working on a custom SharePoint web part (WSS 3.0, not MOSS) that will pull in information for all of the users in Active Directory to build an up to date employee directory. This web part shows things like phone number, address, and other similar fields. The issue that I am having is that, by default, the SharePoint web site on IIS is running as the user IUSR_. This user does not have access to Active Directory, so I am unable to retrieve any user information.
To get around this for testing I have hard coded the credentials for a test user which I added just for this purpose. This, obviously, is not ideal. If anyone removes this user or if they ever change the password then the web part will break and they will have no way to fix it (they have no in-house developers to take it over once I am finished here). To fix this problem, I would like to make the Username/Password custom properties on the web part so I can pass those to Active Directory to retrieve the information I need. The issue I am having with this is that the password is stored in plain text so anyone can read it. I would like it to display as ******** or something similar. Is there a way to make a custom property on a web part a password type?
If this isn't possible, can anyone recommend another way to accomplish what I am trying to do? At this time I cannot change the user that the SharePoint website runs as. Although, if I cannot find any other solutions I will try again to persuade them.
Thanks in advance!
We use a service account for that. That service account is solely used for that. Something like DOMAIN\SPS_AD_READ_CUSTOMER
In our documentation that we deliver when putting the application in production that account is put in the list of stuff that is needed to make the webpart run. If the webpart ever fails, the ITPro can go to the chapter and check if everything is still ok.
It's not ideal, but I don't really know another way on how to fix it.
I would go with custom Editor Part, then set up a control of TextBox with property TextBoxMode set to Password, then override methods from type EditorPart - SynchChanges() and ApplyChanges() to set and retrieve values.
tip: override method CreateEditorParts of a WebPart type to start with.
Or at least could anybody point me to docs about its crazy proprietary url parameters and html field name obfuscation? I can only suppose this is caused by SharePoint...
The main problem is, given a start page built with SharePoint, I can't recreate a form post with a programmative client because:
field names vary, they are appended with a some sort of id, hash, whatever (I think session.wise? Not sure)
tracing HTTP traffic on my side, I see the HTTP request is packed with strange parameters like __REQUESTDIGEST, __VIEWSTATE, and many others
Is this an intentional protection device put up by SharePoint? Which is the underlying architecture and which objects are involved (script callbacks, ... )?
(BTW, I'm not doing anything evil, just trying to extract public government data from a website).
Thanks.
SharePoint is nothing more than an ASP.NET Application, SharePoint completely Built on top of ASP.NET 2.0.
Being said that __VIEWSTATE is nothing but a Hidden Field that has the View State Information
Coming to __REQUESTDIGEST this is an Intentional Protection, this carries some sort of
securito validation which is called FormDigest
And finally to answer your Question, You will not be able to guess field and stuffs unless you have control to change the sourcecode of the application. Reason why the Name of the fields looks like obfuscated is because those controls are not handwritten but generated by the Code of ASP.NET Engine and parser, Reason field having such a name called Naming Container
One suggestion I would say is that, rather than trying to scraping the screen data, you can try alternate approaches, like each of the List in the SharePoint has the XML Feed inbuilt,try to consume it, if you have access to the site, try to retrieve the information using export to excel etc.
In addition to RSS, SharePoint also has a Web Services interface that you can use to get at and interact with data stored in SharePoint in a programatic way.
We have a moss internet facing publishing site, we need to restrict access to this web site to people who have come from another specific web site (using the http header referrer property).
This has to be an automatic process (the user should not have to click ‘login’ or anything like that).
How to do this? Any advice greatly appreciated.
I don’t really want to attempt to write a custom membership provider; that seems like a huge amount of work.
I don't think HTTP-REFERRER is reliabile enough to use as the basis for security. It is very possible/easy to modify or fake the HTTP-REFERRER server variable. Some browsers don't even send it.
If you wanted to do this all in SharePoint, I think the best best bet would be too install a server control on the master page that inspects determines the origin of the request (to your satisfaction) and redirects if the visitor is from the offending location.
Another approach mayb be to implement an ISAPI filter or HTTP module to verify the request origin. You can have this module run before the MOSS filters and modules. This would have 0 impact on SharePoint.
Basically, I think the first thing to do is verify that HTTP-REFERRER is strong enough for your security needs. I prefer the latter option, but I think the former will be easier to implement.
I've been working on a SharePoint project and I have gone the route of loading User Controls through a custom web part.
I have several web controls where I need to dynamically generate hyperlinks (in a loop from a database) that will call certain functions of the User Control when clicked.
When I'm building my own ASP.NET sites, I just add parameters to the hyperlink and check on the page load to see if I need to run any other code when a hyperlink is click.
I'm starting to realize that this probably won't be very reliable inside the SharePoint environment because I don't control the way web page URLs are formed.
I would prefer to have it post back when the hyperlink is clicked and pass some values, but I'm not sure the best way to approach this.
Could someone point me in the right direction?
Thanks.
You can still add querystring parameters to the end of any url and your webpart will pick them up.
The way you create the url will have to be a little more sophisticated in that you cannot assume yours will be the only query parameters on the url.
The SPHttpUtility has some helpful functions.
If you want to avoid the complexity of dealing with and parsing URL's then you need to be using the ASP.NET server controls - the whole idea of them is to abstract out complexity such as that.
http://msdn.microsoft.com/en-us/library/seey0yt3(VS.85).aspx
http://www.startvbdotnet.com/aspsite/controls/linkbutton.aspx