Before I start this question, I’m not able to share any code, or provide a link for this, due a) sensitivity and b) it being on an intranet anyway. So really I’m looking for principles that might help guide our team in resolving a problem.
Our aged intranet (IIS7.5 hosted, ASP/SQL based) is being retired in favour of a rather newer SharePoint solution. The majority of it has already gone over, leaving us with a number of specific applications, that would take considerable time to re-write to sit fully within SharePoint - time we don’t have available right now.
To get over this, what we have done, is present a page with relevant links in an iframe on a new SharePoint page, that people can use to get at the applications - the links are all sitting behind a login screen.
The problem is that when a user logs in on within SharePoint, they correctly see the appropriate link set for them (what they see is permission based). When they click on a link though, the applications open a new browser window, but that new window puts them back at the logon screen again - the session created within the iframe has been broken.
Can anyone outline a method of maintaining session between the link SharePoint, and the application opening in its own window?
Okay, first thing I’d look into is whether the iframe on sharepoint is loading the application differently than the link opening it in a new window. Is one using HTTP versus HTTPS? One using the www. instead of without it? Are they hitting load-balanced servers and thus jumping between two servers?
When you sign-in via the Sharepoint iframe are you seeing the appropriate cookies getting set?
I’m not sure this will help, but have you tried enabling cookieless sessions? IIRC it then puts a session key in the URL as a parameter and allows you to pass state that way. So the link to the application should have an active session id appended to it when it is requested.
There are downsizes to that approach though.
First, if someone where to send their URL to another person, that person would now have access to that application (as it would assume the originators credentials/role). So with that said, they might have to implement additional security measures to validate the session data belongs to the user requesting it.
Secondly, session IDs can be guessed (or at least on certain versions of .NET they could be), so that needs to be taken into consideration too.
1 Like
Thanks. Our man is having a read right now.
It seems that all is in order with those things. In searching for additional info on the subject though, I came across the article below. If I’m reading things right, that suggests that you can’t maintain a session via an <iframe>, and it treats the content opened up in the new window as a completely separate site - security reasons.
http://www.mythoughts.io/articles/iframe-must-die/#.V7L-bfl974Y
Looks like we’ll have to come up with something else, and maybe try to go down the SSO route that we’ve been holding off on.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.