AJAX vs. <Script>: Cross-Domain Access
Read/Post Comments (1)
On the administrative page for our campus events calendar (Bedework), we want the user's name to appear. Because of certain limitations we thought this wasn't going to be possible, but today's efforts found a work-around.
I'm posting the following e-mail for others who might find some benefit in this technical solution.
Apparently Nines pizza and two glasses of caffeinated beverage are good for code monkeys on Friday afternoons.
--
Following how this was accomplished may require an elevated level of caffeine, but here's an attempt to explain it:
1) User logs in, we capture the user's unique ID (NetID) into a cookie. That's all we can get from LDAP at this time because the application's call does not extract any other record data.
2) The straightforward thing to do at this point is to use AJAX (JavaScript) to send the NetID to a PHP, ColdFusion, or other type of script, which will then use its own functionality to talk to the LDAP server to get the full record and return the value to the Bedework page for display.
3) However, we cannot do step #2 because there's no (readily) accessible scripting language on the Bedework server, and AJAX cannot be used cross-domain (for security reasons), so we cannot call a script running on another server.
4) This is where we thought we had reached a dead-end.
5) But, there is another way. Within the XSLT (where we know the NetID), we can include an HTML call to an external JavaScript, like this:
<script src="http://www.cornell.edu/ldap/bwldap.cfm?netid={$NetID}> </script>
6) The essence of this approach is that
a) The <script> tag can point to JavaScript living on any server (no security prohibition)
b) The src parameter value does not itself need to be a .js file (as it usually is)
c) The value of src parameter can include any number of field names and values, which are generated by the XSLT as the HTML is produced
d) The script being called in the src parameter *creates JavaScript* rather than just plain text or XML like AJAX usually does
e) The created JavaScript contains the results of the LDAP server call made by the script on the external machine (ColdFusion in this case)
f) The resulting JavaScript can (and does) set a cookie and/or modify a specific part of the web page to show the user's name via the DOM
6) Thus we now have a cookie that we can reference as needed and we can plop its value into the page any place we want the user's name to appear.
Enjoy.
I'm posting the following e-mail for others who might find some benefit in this technical solution.
Apparently Nines pizza and two glasses of caffeinated beverage are good for code monkeys on Friday afternoons.
--
Following how this was accomplished may require an elevated level of caffeine, but here's an attempt to explain it:
1) User logs in, we capture the user's unique ID (NetID) into a cookie. That's all we can get from LDAP at this time because the application's call does not extract any other record data.
2) The straightforward thing to do at this point is to use AJAX (JavaScript) to send the NetID to a PHP, ColdFusion, or other type of script, which will then use its own functionality to talk to the LDAP server to get the full record and return the value to the Bedework page for display.
3) However, we cannot do step #2 because there's no (readily) accessible scripting language on the Bedework server, and AJAX cannot be used cross-domain (for security reasons), so we cannot call a script running on another server.
4) This is where we thought we had reached a dead-end.
5) But, there is another way. Within the XSLT (where we know the NetID), we can include an HTML call to an external JavaScript, like this:
<script src="http://www.cornell.edu/ldap/bwldap.cfm?netid={$NetID}> </script>
6) The essence of this approach is that
a) The <script> tag can point to JavaScript living on any server (no security prohibition)
b) The src parameter value does not itself need to be a .js file (as it usually is)
c) The value of src parameter can include any number of field names and values, which are generated by the XSLT as the HTML is produced
d) The script being called in the src parameter *creates JavaScript* rather than just plain text or XML like AJAX usually does
e) The created JavaScript contains the results of the LDAP server call made by the script on the external machine (ColdFusion in this case)
f) The resulting JavaScript can (and does) set a cookie and/or modify a specific part of the web page to show the user's name via the DOM
6) Thus we now have a cookie that we can reference as needed and we can plop its value into the page any place we want the user's name to appear.
Enjoy.
Read/Post Comments (1)
Previous Entry :: Next Entry
Back to Top
