Restricted sites

[Scottcamp]

I would like to know how to password protect a site so that members only may get in after they pay a yearly fee. How do I create the password protect, and how do I only allow it after this fee has been paid?

I will end up posting it on godaddy probably.

[PeOfEo]

pick any server side language to do it. Its not hard. You just simply have a feild in the db that has paid or not paid and it would eb a date feild. Then whenever they login you run a date difference function and see if it is a year later. You going to pick a windows or linux server on go daddy? You can do what you want to do with ASP, ASP.NET, PHP, CGI, JSP, Cold Fusion. I use asp.net myself and wrote an article about how to make a simple login system with asp.net, but if you needed high security or something you should not use my method (but rather forms auth and https protocal). http://www.webreference.com/programming/asp/quasi/ is my article. It will do its job just fine unless stuff like credit card numberws and social security numbers are involved, and that those are only a login away.

[ray326]

You can use Basic Authentication on the server with no extra coding required unless you want to do role-ish things.

[Scottcamp]

Thanks, I have never stepped in this realm before...It's always been just basic web development. I'll probably go with a windows based server, since I have little experience with Linux. I will probably use the ASP like you referred me to. Thanks for the article.

Where can I find a date/time function?

And will this ASP page protect the directory so they cannot tack a page behind the password page on their favorites and never log in again?

[ray326]

You can turn on Basic Auth in your IIS configuration console.

[PeOfEo]

Originally posted by ray326
You can turn on Basic Auth in your IIS configuration console. But will this be effective with a lot of users? I think a data base soltuion would be more feasible.

[Scottcamp]

I used PeOfEo's site (http://www.webreference.com/programming/asp/quasi/)to create pages, but I come up with this error when trying to access the login.aspx page.


Server Error in '/' Application.
--------------------------------------------------------------------------------

Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".


<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>


Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.


<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>


Any ideas?

[ray326]

Originally posted by PeOfEo
But will this be effective with a lot of users? I think a data base soltuion would be more feasible. There's no reason the id/password data store for basic couldn't be a table in a database. The most common data store for IIS applications is probably an NT domain or an AD group.

[PeOfEo]

Originally posted by Scottcamp
I used PeOfEo's site (http://www.webreference.com/programming/asp/quasi/)to create pages, but I come up with this error when trying to access the login.aspx page.


Server Error in '/' Application.
--------------------------------------------------------------------------------

Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".


<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>


Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.


<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>


Any ideas? Tons of reasons. Okay, do you have a web.config file? If so turn the errors off, like the message says so we can see what is actually happening.

[PeOfEo]

Originally posted by ray326
There's no reason the id/password data store for basic couldn't be a table in a database. The most common data store for IIS applications is probably an NT domain or an AD group. Well Iknow forms works well with a db. But I thought windows and basic caused problems. I never use either of course, I always just do like what I did in my article, no auth, for a site that does not need to be super sequre where the login is a means of identification, or I use forms.

[ray326]

We run Basic against an NT domain on our IIS-based apps with no problem. The users like it because it's synchronized with their network login, the admins like it because there's zero administration, the security guys like it because it satisfies the requirement that ALL requests to an app be authenticated.