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.
Related
There is an existing app in MOSS, which allows to create polls for a call center, operators fill them out as they call targeted customers. Then this Web app outputs the results of this poll.
Is it possible to change the interface language of this existing web app? Operators don't understand English. If it's not about language packs, it would still be easier for me to embed new names and labels, rather than rewrite in a system I am not familiar with.
Also, is it possible to change the authentication type from Windows authentication to regular username/password check (username and password will be stored in DB or somewhere only for this site)
If it is possible, can you direct me to some kind of tutorial, help or manual which would show how to do it?
On MSDN it's written that language can't be changed, but I'm not sure whether it's about the Web app language.
Thank you.
Have a look at chapter 4 in our free SharePoint Development Guidelines.
I have no mutch idea about web app language
But I shall share you the links for sql authentication
http://weblog.vb-tech.com/nick/archive/2006/06/14/1617.aspx
http://www.codeproject.com/KB/sharepoint/moss_enableforms.aspx
For SharePoint it is possible to create different web's in different languages. Not that i know you could use one web in different languages.
But, it may be funny or not, a crazy idea or not, but could work: before dumping rendered contents to user, maybe you could extract text values excluding form values, post them to Google or Bing translator and put back translated values? You can override global.asax file and use PreSendRequestContent to modify contents just before they are sent to client.
If your company is not huge and it's an intranet page, then, althought slower, but it could work. Better than nothing.
PreSendRequestContent. This event
signals that content is about to be
sent to the client. This provides an
opportunity to modify the content
before it is sent.
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.
We'll be upgrading a client's MOSS public internet site soon from a Cumulative Update to SP2 and are conscious that there will be downtime (to perform the upgrade and possibly troubleshooting!). We would like to add a holding page so that visitors still get access to key contact details and a message that the site is under maintenance.
Does anyone have any tips for doing this type of thing with SharePoint? I know of the app_offline.htm file that when dropped into the web root, will automatically prevent access to the rest of the site but wasn't sure if this was standard practice in the SharePoint world?
Any tips?
Cheers, James.
If the app_offline.htm works for you, then by all means, use it.
I think that it will the best option for you, and to the best of my knowledge SharePoint doesn't have any other means of putting itself offline.
As this is a public intranet site you are updating, presumably there is already a test environment for it that is close or the same in configuration. It is important to follow exactly the same steps for updating the test environment as you would for production. These should be documented as well and followed to the letter to reduce the likelihood of mistakes. This way you are much less likely to run into problems.
I would try app_offline.htm as you suggest (like Magnus I don't believe there is another way to take SharePoint offline). If your test environment updates with this in place you should be fine.
I am creating sharepoint custom solution that will show number of drop down in page. The drop down data is shared in may pages.
I want to persist selected values of the user such that when ever he visit that page or any other page that have same drop down, he should be able to see is saved value pre selected in drop down.
To implement this I have a number of options. Please suggest the best for SharePoint
1)Sharepoint User profiles
2)Sharepoint list
3) Cookie
4) Isolated storage?
Options 3 and 4 here are clientside. But I am looking for any other way that SharePoint provides to save user preferences/personalization information.
Which one is the correct way of doing that in SharePoint?
Thanks
One issue you should be aware of with user profiles is that they are only available for MOSS (as opposed to WSS). In WSS each site has their own User information list. If the solution you are building will need to run in both MOSS and WSS environments, you should plan accordingly.
jt
My instinct tells me to use cookies for this, if it's a fairly simple state you need to persist. This seems to be a part of the UI logic, and I wouldn't bind that to the profile storage.
Pages and web parts have personalization stores as well, but they are generally not shared between instances.
I would go with profile storage, because that's the sort of thing it's there for, although generally when you are writing custom code in SharePoint the idea of best practices kind of gets thrown out the window.
I am working on a project that is replacing an old portal system (Plumtree) with sharepoint and we want to make the transition as smooth as possible.
One thing we are look at currently is taking all the gadgets (Plumtree term for WebParts) and making sure they appear in the same place on the users new MySite.
Plumtree holds this information in a simple table containing the user, page, gadget and position information. I want to find a way to automate reading this table and putting the new WebParts on the users MySite and not have to manually set it up for hundreds of users.
I'm told modifying Sharepoint tables in SQL Server directly is not a good option as it may affect our support arrangements, but if it saves doing this by hand then I would concider it.
Other options that spring to mind are creating a equivalent table and using API calls to load the WebParts the first time the user accesses their MySite.
Any better suggestions?
You are right, messing directly with databases are not supported nor recommended.
Unfortunately, there are not much ways to modify MySites, the best way I know come from the MOSS Team Blog: http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx
The way we did it was pretty much what is described in the link above (http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx).
Your best bet is probably to staple a Feature to MySite creation and have it poll the plumtree database, find the gadgets for that user, and add a 'Page Viewer' web part for each, pointing to the gadget's location. That said, you may want to reconsider blindly migrating all your plumtree gadgets into SharePoint. There may be much better 'SharePointy' ways to provide the functionality that your gadgets are currently providing.