StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
9534592
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-03-02T14:05:35.697
FavoriteCount
0
LastActivityDate
2012-03-02T17:36:17
LastEditDate
2012-03-02T17:36:17
LastEditorUserId
461813
OwnerUserId
545332
ParentId
9533485
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
<p>The only caveat in Treffynnon's answer is that it requires you to have access to both systems to create a sort of "login code" web service that the two can use to communicate. If you only have access to the first site (the one that you want to include the iframe on), what I would do is the following (please note that this is not as secure as Treffynnon's answer):</p> <ol> <li>load the page without the iframe</li> <li>using ajax, query your server (over SSL!) for the username and password that you'll need to submit to the other server.</li> <li>dynamically create your iframe, populated with a form that is basically identical to the login form on the other server, submitting with the same "method" to the same "action" as the other form. Then dynamically submit it. This should set the appropriate login cookies on the client so that they are logged in. Make sure you use SSL everywhere.</li> <li>dynamically redirect the iframe to the page that has the chart you want to see.</li> <li>obliterate any javascript variables that held secure login information.</li> </ol> <p>Potential issues:</p> <ul> <li>Some login processes are extremely finicky, and may be impossible to log in with using this method.</li> <li>You're dramatically increasing the number of attack vectors on your site. For example: step 2, querying the login credentials, assumes that your security is adequate to prevent people querying for data they shouldn't have access to.</li> <li>All of this assumes that it would be OK for the end user to access the login credentials, say, they have one username and password that they use at both sites. If you have 1 site-wide login that you're using to give your end users access to something they wouldn't otherwise get, then this will expose your login details to all of your users and you shouldn't do it. In that case, your only option is to do something completely on the back end. If you have access to the code for both sites, use Treffynnon's suggestion, otherwise you'll have to access and download the chart on the back end and re-display it for your users.</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POPassing Username and Password with IFrame
  singulars
  PostTypePostTypeId
  PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USTreffynnon
UserOwnerUserId
1. USJason
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
2. VO
  singulars
  PostPostId
  PO
  UserUserId
  This table or related slice is empty.
  VoteTypeVoteTypeId
  VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.