View Complete Post
currently I'm building a custom tab for Sharepoint Server 2010 and at the moment I'm stuck on the following issue,
with the first debug deployment Visual Studio sends the .js file that provides some functions for the ribbon elements from Scripts folder in the VS project
to Sharepoint Server.
However, it won't apply any changes I did on the script afterwards to the file on the server.
So the effect is, that as soon as I do the next debug, the previous script is being used by Sharepoint and the new version, containing the new code, is left aside.
It seems to me as if Visual Studio would only deploy the .js file just once and then rely to this copy, maybe there are some configuration settings to make, but after hours of research, I still can't figure out where things do go wrong or what
configuration to apply to update the script on the server.
I couldn't locate the file on hdd either, even searched the whole fs but the results showed only the new script file.
Any help on this would be very much appreciated, this issue drives me nuts and consumes plenty of time ;)
Workaround at the moment: each time the script is changed, set up new project... :D
P.S: Yes, I did flush
The challenge I'm facing is that I've set up a small farm for a client and the solution consists of three web applications (mainly scalability). What I primarily want to achieve is single sign-on (for authenticating users accessing the site) between the
web applications, using FBA. I haven't found a single source indicating that merely using forms login is the way to achieve SSO in SP 2010. Rather, everything points to using a STS.
We might end up using ADFS 2 but for now I've built a custom IP-STS, based on Starter STS. The problems that have arisen are related to establishing trust between SharePoint and the STS. Of course I've configured a SPTrustedIdentityTokenIssuer with the proper
certs and so on. As far as I can tell, I get redirected to the STS login form, get authenticated properly and redirected back to the calling RP.
What happens next is that if I have multiple RP:s configured (that is, one default realm and one provider realm) in the token issuer, upon redirection back to the calling RP the browser is stuck in an endless redirection loop. I've tried to use Fiddle to
determine the "end points" of the loop and it seems to be a chain consisting of
/_trust, _layouts/authenticate.aspx and
/_trust/default. It's worth noting that authenticate.aspx seems