I have two sites - old and new one.
The newest is Sharepoint 2010 portal. Several part of it are under construction and when user requests site which is under construction I need to return page from old portal.
I've found an article which describes how to implement Sharepoint 2010 reverse proxy using URL Revrite and Application Request Routing.
But URL to old site should contain a dinamically generated parameter.
Is this possible to interfere in Sharepoint or IIS working process to generate this parameter and change dynamically this URL address before it will be processed?
HttpModule will allow you to run some codez inside HttpRequest processor, but I'm not really sure you wanna go that route...
Related
I have an ASP.NET Core application hosted on a server which doesn't access the internet directly for security reasons. So if I used any SDK (ex: FCM SDK) it can't initialize a connection from the application.
The SDK is internally calling an API like fcm.googleapis.com; I need to create something which intercept the SDK request and forwards the request to this route (ex: 192.168.1.45:51514) and I configure the proxy to navigate to the desired URL.
I'm thinking for multiple solutions as follows:
Create a middleware that intercept the SDK requests and changes its base URL to the desired URL (I don't know if it'll work or not).
Create an intermediator project which I can call and just call it then the SDK integration inside the intermediator project (it works but searching for a better solution).
Get the SDK source code as it's an open source and change the URL to be configurable not hardcoded as it is.
Please advise for what is the best practice solution for this issue.
I'm new to the SharePoint 2013 .Net Client API. I want to programmatically crawl all of a SharePoint site. I want to fully extract lists, document, pages, everything!
Ideally I want to start with the root of the website and crawl everything from there.
Can someone give a high-level overview of the basic steps involved? For example, do I need to create a catalog, or can I simply crawl if I have the admin credentials?
I'm using C#, .Net 4.0, and the Client runtime API (not REST).
Some of the links that were helpful for me :
1. Crawling with Rest API or PowerShell - Start a crawl manually via SOAP or REST WebService
2. Recrawling using code - http://sebastian.expert/force-web-whole-list-library-re-crawled-search-sharepoint-2013-using-api/
I believe that everything in SharePoint lives under a List. Essentially, I fetch the Lists belonging to a Web and fetch all the ListItems from those. I ignore Folder and File collections as these are duplicates.
I am stuck in a situation where i have a bunch of urls and i have to distinguish them based on whether they belongs to website or webapp.
I tried to look at Response Header from the request and discovered that i can use server field & powered By field to check it.
But for most of the requests they are disabled so is there any other way to distinguish webapps from websites.
There is no way to identify that website id webapp or website on basis of user agent or some other property. its just term, here other question which might suite you - What's the difference between a web site and a web application?
I have a standard ASP.NET 2.0 website.
It has a webpage page.
I have a webpart in my Company.Web.dll that I display on my webpart page on my website.All is good!!!
I would like to use this same webpart in SharePoint 2007.
I have a "site definition" project in VS2008 using Extensions for SharePoint 1.2. I have tried various ways to add the webpart from an outside assembly to my site definition. I have been able to deploy the webpart (where it is added to the webpart list of a webpart page) but I have been unsuccessful at adding the it to a page.
My Glorious Failures:
Created a shell webpart to just display the existing web part, basically just using my part as a control.
Attempted to modify the X.webpart and X.xml files created by VS2008 when you create a new webpart.
Both result in the following error while adding the web part to the page:
Exception
Microsoft.SharePoint.WebPartPages.WebPartPageUserException:
Cannot import XXXX Web Part.
at Microsoft.SharePoint.WebPartPages.WebPartImporter.CreateWebPart(Boolean
clearConnections) at
Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager
manager, XmlReader reader, Boolean
clearConnections, Uri webPartPageUri,
SPWeb spWeb) at
Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager
manager, XmlReader reader, Boolean
clearConnections, SPWeb spWeb) at
Microsoft.SharePoint.WebPartPages.WebPartQuickAdd.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String
eventArgument)
Is there a special way I need to add my existing webpart to my site definition?
This sounds like a problem resolving the GUID at deployment time, as you can read about in this SO question.
To find the details of why the web part won't import, check the ULS logs. These are typically located at %CommonProgramFiles%\Microsoft Shared\web server extensions\12\LOGS. An entry will be logged here at the time you attempt to add the web part to the page. This should give you more detail.
My guess is that it is a code access security issue. Your web part must be strongly signed and needs a SafeControl entry in the web.config of the SharePoint web application. Apart from these things you should be able to just add it to the Global Assembly Cache to test if it works (best practice is to write a CAS policy file). See Deploying Web Parts in Windows SharePoint Services for more details.
I would try these steps before trying to integrate it as part of a site definition. Then at least you know the web part will actually run.
Also, VSeWSS is really designed for developing your web part using it from the very start. If you have the original source, you could try creating a new web part with VSeWSS and then replace with your custom code and update the .webpart and feature XML files. Then it should behave a little better. If you haven't committed to VSeWSS, try WSPBuilder as it's less painful.
ASP.NET webparts and Sharepoint Webparts are NOT the same. You should be able to use a ASPNET webpart within Sharepoint. See the following table:
ASP.NET 2.0 Web Part
For most business needs.
To distribute your Web Part to sites that run ASP.NET 2.0 or SharePoint sites.
When you want to reuse one or more Web Parts created for ASP.NET 2.0 sites on SharePoint sites.
To use data or functionality provided by Windows SharePoint Services 3.0. For example, you are creating a a Web Part that works with site or list data.
SharePoint-based Web Part
When you want to migrate a set of Web Parts using the SharePoint-based Web Part infrastructure to Windows SharePoint Services 3.0.
To create cross page connections.
To create connections between Web Parts that are outside of a Web Part zone.
To work with client-side connections (Web Part Page Services Component).
To use a data-caching infrastructure that allows caching to the content database.
For a Sharepoint webpart to work in a standard ASPNET application you would need to recreate your webparts in Visual Studio (as an ASPNET webpart) without the Sharepoint 2007 references for it to work correctly.
One nifty tool which I have used in the past is the SmartPart Worth checking out:
This lets you create a ASP.NET usercontrol (visually) in Visual Studio and then host this in Sharepoint. The smartpart acts as a wrapper wepart for your user control. Think of it like the page viewer webpart in Sharepoint except instead of it being HTML pages its ASP.NET UserControls.
You would need WSS 3.0, SharePoint MOSS or 2007 to use ASP.NET 2.0 WebParts. SharePoint 2003 or below and WSS 2.0 or below do not support ASP.NET WebParts.
I have a MOSS 2007 instance and a web app (Site Collection) in port 80 that has an extension through port 443 to enable https.
This instance has an asp.net web app that is inside the Site Collection. This asp.net web app enters https protocol when one of its qualifying aspx webforms is called, but when the user leaves the form the https protocol is still active for the rest of the navigation.
You must know this:
All site content pages must be and are sharepoint pages (site content).
All URLs are and must be relative.
The asp.net web app is using an http module that can handle http-->https and viceversa (it works by overriding the page_load event).
I'm looking for a native way to do this in SharePoint (MOSS 2007) or using IIS.
Have you tried to link the user to http://./server-relative-url at the end of your custom form? I don't know if this will work but its the best I can think of if you must use relative URLs.
Edit:
I don't like the 'feel' of it, but the only thing I can think of right now is to use an HTTP module to update the https links in the page. If it's SharePoint-generated content that you need to update en masse then this is practical and efficient, and perhaps the only option?
You would need to work out some logic (maybe add something to the page) so the HTTP module knows when to activate.