Permit external websites to open FamilySearch URLs in an <iframe>
To promote FamilySearch I include links to pages on the FamilySearch website in my personal web site.
Recently a change was made to the behavior of FamilySearch that blocks these URLs if they are displayed in an <iframe>. An <iframe> is used by a web page when it wants the referenced web-page to only occupy part of the browser window. As a consequence of this recent change if I try to open a FamilySearch page it is replaced by the Signon page even if I am already signed on from that browser. If I fill in my identification and password the originally requested page is displayed, but it replaces the entire page that made the request, not just the iframe. It is reasonable that FamilySearch requests identification of who is asking for the page.
Comments
-
Community member (not FamilySearch representative)
Interesting request. Referral to sources/historical records should require login - because different accounts may have different access to the resource. This is a contractual obligation which FamilySearch must implement. I don't think there will be a way around this. I am unaware of whether there are universal permalinks which would be accessible by anyone (certainly some records/images may not require login but many/most do). Not requiring login would be a breach of contract if required by the record custodian. Further - linkages contractually requiring login but which may have previously been circumvented in iframe (as you indicate) may be a violation of the FamilySearch user contract - typically images of records are allowed for personal genealogical/fair use only but not for publication/distribution unless copyright permission has been granted (hopefully you have obtained such permission). Interestingly a URL reference to the record alone might not be considered publication/distribution - but embedding the reference within an iframe to display the actual image probably is considered such. I wish genealogical information were freely accessible/shareable - but we live in a highly litigious society (very unfortunate - and these days seems to be growing). I am unaware of a method to embed the login within an iframe (sorry not knowledgeable enough to address your concern but here is a reference for interest: https://www.w3schools.com/tags/tag_iframe.ASP) and I do not know if there are reasons for the change you indicate has occurred. Perhaps requiring users of your site to login to FamilySearch prior to accessing pages with iframe references would be a workaround? Perhaps FamilySearch development will respond and let you know (not likely - their resources typically don't allow response to individual technical queries - you will have to wait and see).
0 -
@genthusiast Thank you for your comments. When I encounter this situation I
amsigned in. I have verified that the site is aware that I am signed in another browser tab, and indeed in that browser tab I am looking at exactly the same page that I am trying to open in the <iframe>.I fully respect that it is desirable for FamilySearch to be aware of which users are accessing which resources within the site. The required login would not be as disruptive if once it is resolved and the site displays the requested page it did so within the <iframe> from which the page was requested. It is because the image is displayed in the whole browser tab, rather than the <iframe> that I can no longer use this as a technique to copy information from the image into the containing web page, as that containing web page is overwritten.
0 -
At the moment I cannot reproduce this problem except if I am not signed in. The handling of the sign in is still problematic because when the requested page is finally displayed it replaces the requested page instead of remaining within the <iframe>. The following URL demonstrates this.
This page has a link to https://www.familysearch.org/ark:/61903/3:1:939J-DZ9M-SM
0 -
Yes understood - thanks for the link. So in the past [show link] would have displayed the image without requiring login? And now instead the login overtakes the referring page and does not remain in the iframe. I still think your solution is going to be 'some script/notice' requiring the user to login to Familysearch first or on another tab before opening any links referring to Familysearch.org.
There used to be a option to request 'developer' access (a developer contract was required) which would allow 'authentication handling' etc. I do not think that development group is any longer available to 3rd parties
https://www.familysearch.org/developers/
- all Familysearch 'development' is internal/contracted - and I doubt they will respond to your request. The current functioning is probably so that just such 3rd-party adhoc 'development' won't 'hijack' the authentication process. Meaning all authentication for Familysearch resources has to go through Familysearch.org domain - thus would not 'route' through another domain. Again I may be speaking out of turn - not knowing the needed particulars of iframe attributes - but this might explain what is occurring. Again I wouldn't know why it would have changed - unless some security audit/scripting has been implemented differently.
0
