Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Nesting an Existing Website Under DotNetNuke Portal SecurityNesting an Existing Website Under DotNetNuke Portal Security
Previous
 
Next
New Post
12/15/2006 9:13 AM
 
Nina, it's too close to Christmas for ba-humbuging :)

I think I see your concern though. You are saying that someone could view the source of the iFrame and pull the link and go directly to the URL, correct? I am under the impression that only "authorized" users would be given access to the page with the iFrame. The iFrame could be changed quickly and almost effortlessly to have the source point to a different page if someone is suspected of bookmarking it. By changing the "true" default.htm page to something like secure2468.htm and could be changed regularly so book-marking of the site would be more difficult. I would then create another default.htm (HTTP-REFRESH) page to redirect users to the DNN site (they would not be able to get to the 'secure2468.htm' page unless they were logged in (just use DNN for security to keep the page hidden from un-authorized users).

The initial steps to make this work:
1. Rename the default.htm page to somethingElse.htm.
2. Make a new default.htm page that redirects users to the DNN portal.
3. Create the page in DNN to house the iFrame and set the page security...add the Text/Html module (you could add extra security here as well)...insert the iFrame code.
4. Log out and test as an un-registered user.

The maintenance / updating steps:
1. Change the somethingElse.htm page to somethingNew.htm
2. Log into DNN and change the iFrame code to point to somethingNew.htm

I have a shopping cart hosted by another company for my website. I added the shopping cart management area in an iFrame for the administrator/owner of the site so he doesn't have to have a seperate page to open and it's working perfectly. My next step will be to add the shopping cart itsself to an iFrame for all of the other users.

Hope this helps...

Billy
 
New Post
12/15/2006 11:00 AM
 

As far as quick/easy solutions go, the iFrame idea seems like a good one. In time, an A-Z port of the existing site to DNN would be more complete and look better. But for "ver. 1" using DNN, I will try iFrame. After users register/login to the new DNN portal, I will probably display a message that says "If you're having trouble viewing this site, click here" and give them an alternate, non-iFrame route to the existing site.

Redirecting the default/index page for the existing site to the new DotNetNuke portal: nice touch. Every page of the site is *not* requiring security; I simply want to add DNN registration for the existing user base, and this redirect solution should work well for that.

Any reason why I wouldn't want to use the iFrame Module (this DNN installation is 4.3.7; maybe earlier DNN releases do not have an iFrame Module?) In that case, the iFrame code in a Text/HTML Module would be the way to go I suppose. I just took a peek at the iFrame Module, and from what I see it has some interesting/unfamiliar settings like URL Parameter and QueryString Parameters. I'll have to browse the iFrame Project for more info.

Thanks for the suggestions - every one of them.


If a problem can be solved, there's no use worrying about it.
If it can't be solved, worrying will do no good.
 
New Post
12/15/2006 12:15 PM
 
> restrict the old app to only taking requests from the DNN host

I presume that one can do this in IIS?  Can you provide a few hints on exactly how to do this?



Joe Craig
Patapsco Research Group, Ellicott City, MD
DotNetNuke Development and Services (http://patapscorg.com)
 
New Post
12/15/2006 12:33 PM
 

> Why bother using DNN then?

For many of us ... perhaps more familiar with web applications than in building DNN modules, or having legacy stuff that we'd like to get running, but in the context of a DNN site ... this is important.

> The whole idea of moving to DNN is either for management or security -

Absolutely!  But, short-term, hosting stuff inside of a DNN site, and taking advantage of DNN's management and security features -- with an emphasis on the security issues -- is extremely attractive.

> You would have to set up iframes I guess, but I've never heard of a html file not being accessible
>once a person knows the url.

iframes work well.  But you are right that the use of iframe doesn't hide the basic URL from the user.  What's needed is additional security on top of that. 

I'm one of those looking for the solutions to this issue ...

Either way - I've been looking for that elusive *no work required* deal and .. I'm still looking.. oh and for santa claus too because it's that time of the year..




Joe Craig
Patapsco Research Group, Ellicott City, MD
DotNetNuke Development and Services (http://patapscorg.com)
 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Nesting an Existing Website Under DotNetNuke Portal SecurityNesting an Existing Website Under DotNetNuke Portal Security


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out