While I am sure this isn't a common problem, I am also sure that I could not be the only one that encountered it. So hopefully the solution below comes to someone's benefit in the future.
I had a RADEditor placed in a panel that was at load-time initially hidden, using server-side code. This means that the RADEditor was never rendered. At a later point, when the user kicked off an event, the server-side code made the panel "visible". Normally this would be an issue, however all this happened using AJAX, in my attempt to speed up page processing and avoid full postbacks.
Well...talk about unexpected results. The first time the RADEditor rendered through an AJAX partial-postback, the RADEditor ended up rendering strangely. In my case, the height was way larger then it should have been, causing it to overlap the controls directly beneath it. Changing the views on the bottom cause the control to immediately snap to the correct height, or if I cause another AJAX partial-postback, it would then render correctly. Obviously this is a problem because end-users would not like or know that those things would fix the problem. End-users want it to work the first time.
Ended up that because the RADEditor didn't render on the initial page-load, the corresponding CSS files were not loaded. When the AJAX partial-postback occurred, it loaded the CSS files, but not in time to the RADEditor to make use of them, causing some unexpected rendering. I figured out which CSS files were missing and forced them to load (using server-side code) at the time of initial page-load. This way, the first time the RADEditor is rendered, the CSS file were already loaded and available to complete the rendering process. Below is the code I used for server-side loading.
Tekk Programming
Friday, May 2, 2014
Tuesday, January 14, 2014
Implementing SSO w/ DNN and SmarterTrack
So this I have to admit had me spinning my wheels for a while, but I finally figured it out. So below is a step-by-step guide on how to implement SSO using DNN as the main login site, and SmarterTrack as a secondary site that authenticates using the DNN login.
Requirements: Please note that in order for SSO to work "out-of-the-box" so to speak is that both site must be on the same domain. (ie: www.mydomain.com & support.mydomain.com) If the domains are different this method will not work and you will have to implement a custom SSO scenario.
Note: This write-up was performed on DNN 06.02.09 and SmarterTrack 9.5
Requirements: Please note that in order for SSO to work "out-of-the-box" so to speak is that both site must be on the same domain. (ie: www.mydomain.com & support.mydomain.com) If the domains are different this method will not work and you will have to implement a custom SSO scenario.
Note: This write-up was performed on DNN 06.02.09 and SmarterTrack 9.5
- Open up the web.config files from both DNN and SmarterTrack sites.
- Copy the entire "machineKey" tag line from the DNN web.config and paste it into the SmartTrack web.config.
- In both web.config files add the following parameters to the end of the "forms" tag: domain="MyDomain.com" enableCrossAppRedirects="true"
- In the SmarterTrack web.config add the following to the beginning of the "forms" tag:
name=".DOTNETNUKE" - Log into your SmarterTrack site as the administrator
- Click the settings icon.
- In the navigation pane - Navigate to System Settings > Setup > External Providers
- In the options tab check "Enable login provider".
- Click the "Login" tab which is now available and enter the following information:
Note: Replace www.MyDomain.com with your DNN domain
Web Service URL: http://www.MyDomain.com/login.aspx
Web Service Password: [Leave This Blank]
Forgot Password URL: [Copy The Link From Your Login Page's 'Retrieve Password' Link]
Select a default role for users - Check "Enable single sign-on cookies from other sites".
- Click save.
Congratulations, you have successfully setup SSO between DNN and SmarterTrack.
Note that you have to have a matching User in SmarterTrack with the same UserName as found in DNN for SSO to work, otherwise you will get an error. So may have to manually create SmarterTrack usernames to match DNN accounts.
Tuesday, April 23, 2013
The underlying connection was closed: The connection was closed unexpectedly.
This had to be one of the most vague, non-descriptive errors I have received in my entire career as a computer programmer. Not to say that it was the worst message, there are still a few that are better than this one, but this is definitely up there in the list.
I wrote some ASP.Net server-side code that verified a user's entry of a website address. It did this by creating an HTTPWebRequest and retrieving the webpage data for the URL that the user entered. If the code retrieved HTML data, then the website address supplied was correct, otherwise the website URL supplied is considered invalid. The idea is sound, and in most cases worked perfectly...that is until today. I get a support ticket from a client that stated they were receiving an error that said: The underlying connection was closed: The connection was closed unexpectedly.
I immediately tried to reproduce the error, because as we all know end-users cannot always be trusted to tell the whole truth. However, to my surprise this one was a valid complaint. So I started scouring the code as well as the internet to try and find the cause and remedy for this poorly worded error. I found others with similar problems, some claimed it was a timeout issue, others claimed it was an encoding issue, and other claimed it was a keep-alive issue. Alas, all those remedies did nothing to fix my problem. I spent the better part of the morning trying every trick I knew to determine the problem. I even began picking apart the return HTTP Headers using Fiddler.
Ultimately I determined that the reason the connection was being closed, was because the web server was forcibly closing it. It had nothing to do with me having bad code...or not entirely at least. The web server was rejecting any HTTP connection requests that did not also identify the platform that the request was coming from. An annoying feature to say the least. So I decided to "spoof" a MSIE 8.0 platform running on Win7. Now that my code was identifying itself as a particular platform, the web server allows the HTTP request through and the HTML data was finally retrieved.
I determined the UserAgent string by using a free online generator: http://user-agent-string.info
I have the code shown below. I hope that this post can help someone out there having a similar issue.
I wrote some ASP.Net server-side code that verified a user's entry of a website address. It did this by creating an HTTPWebRequest and retrieving the webpage data for the URL that the user entered. If the code retrieved HTML data, then the website address supplied was correct, otherwise the website URL supplied is considered invalid. The idea is sound, and in most cases worked perfectly...that is until today. I get a support ticket from a client that stated they were receiving an error that said: The underlying connection was closed: The connection was closed unexpectedly.
I immediately tried to reproduce the error, because as we all know end-users cannot always be trusted to tell the whole truth. However, to my surprise this one was a valid complaint. So I started scouring the code as well as the internet to try and find the cause and remedy for this poorly worded error. I found others with similar problems, some claimed it was a timeout issue, others claimed it was an encoding issue, and other claimed it was a keep-alive issue. Alas, all those remedies did nothing to fix my problem. I spent the better part of the morning trying every trick I knew to determine the problem. I even began picking apart the return HTTP Headers using Fiddler.
Ultimately I determined that the reason the connection was being closed, was because the web server was forcibly closing it. It had nothing to do with me having bad code...or not entirely at least. The web server was rejecting any HTTP connection requests that did not also identify the platform that the request was coming from. An annoying feature to say the least. So I decided to "spoof" a MSIE 8.0 platform running on Win7. Now that my code was identifying itself as a particular platform, the web server allows the HTTP request through and the HTML data was finally retrieved.
I determined the UserAgent string by using a free online generator: http://user-agent-string.info
I have the code shown below. I hope that this post can help someone out there having a similar issue.
Subscribe to:
Posts (Atom)