Editing web.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

<system.web>

<compilation defaultLanguage="vb" debug="false" />
This line should be set to debug="false". Setting debugging to true will reduce performance and increase memory usage as debugging symbols must be created and loaded. The garbage collector is also not as performance sensitive when it debugging mode.

<customErrors mode="Off" />
Set this to "Off" to display normal ASP.NET errors to clients with details on the error presented. Set to "On" to hide these detailed error messages from the clients for increased security. You can also set it to "RemoteOnly" so that clients do not see detailed messages but you can terminal into the webserver and see the errors locally.

<authentication mode="Windows" />
ASP.Net's built-in authentication modes are not used. Leave this set to "Windows".

<authorization>
         <allow users="*" />
</authorization>
ASP.Net's built-in authorization features are not typically used, so leave this set to users="*". You may choose to further restrict who has access to your forums using these settings, but such a configuration is not supported or tested.

<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
The Lasto forums do not currently provide trace debugging facilities so leave this set to enabled="false".

<sessionState mode="InProc" cookieless="false"  timeout="20"  />
Lasto uses session state to handle caching of user permissions and settings. You cannot use the "Off" mode or Lasto will NOT function!
The modes you can use are "InProc", "StateServer", and "SQLServer".

• InProc - this stores session state inside of the ASP.Net worker process. This is definitely the fastest way, but has two drawbacks: If the process is recycled by IIS, sessions will be lost so any currently logged in users will be mysteriously logged out temporarily (their login cookie will get them logged back in.) The biggest drawback is that this method is not scalable since session state is tied to a specific machine.
• StateServer - this stores session state in a separate process. The benefit is that the state does not die if IIS recycles the ASP.Net process. Also, several webservers can connect to a single server running the state (or it can run on one of the webservers.) Be sure the aspnet_state service is running, and set the stateConnectionString is configured properly on each webserver. Consult the ASP.NET docs for more information. (Slower by 10%).
• SQLServer - this stores session state in a SQL Server database. This is the slowest mode (by about 20%), but also the most robust as it can handle huge webfarms and sessions persist even through a webserver or database server restart. Consult the ASP.NET docs for information about setting up the ASPState database.

So, which one should you use? Most smaller websites running on a single webserver (or a shared hosting server) should go with InProc, as it is the fastest and least complicated.

Sites with several webservers in a farm configuration should probably use StateServer and designate one of the webservers (or the database server) as the state server. Configure the state service as described in the documentation.

Sites with many webservers or high-availability needs should probably use SQLServer. Configure the state database as described in the documentation. I highly recommend the "persistent" method using the persistent script, as you can set permissions on the ASPState database and they will be permanent. If you use the tempdb method, and the server is restarted, you may need to grant permissions again since tempdb was recreated.

The Cookieless property tells ASP.NET whether or not to use a cookie to track sessions, or to append a session identifier to the end of all URLs. I recommend using cookies unless you have specific reasons not to (set cookieless="false".)

The timeout tells ASP.NET how long to keep the session alive between requests. The default, 20 minutes, means if a user refreshes a page every 1/5/15/19 minutes their session will not expire. But if they have not requested a page within 20 minutes, the session will be erased. For users with cookies enabled, the login cookie will automatically log them back in when this happens and they will probably never know. It is really just a performance-tuning feature. You can decrease the login load by increasing memory usage or vice-versa. If you aren't sure, just leave it at the default 20 minutes.

<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
This sets the encoding type used by the forums. Typically leave it set to utf-8.

</system.web>

 

That ends the system settings and now we will look at application settings. If you are using a web farm with two or more web servers, you should keep all of these values set the same (and keep the theme files synchronized), lest your users experience errors.

<appSettings>

<add key="sqlConnectionString" value="Data Source=127.0.0.1;Initial Catalog=Lasto;Integrated Security=SSPI" />
sqlConnectionString sets the connect string (or DSN if you prefer) that Lasto will use to connect to the database. It should specify:

• Data Source - either IP address, DNS name, or NetBIOS name of the machine to connect to. Use 127.0.0.1 for a local database.
• Initial Catalog - the name of the database to open. If you are on shared hosting, you will probably have been assigned a database to use by your service provider.
• Integrated Security=SSPI - tells Lasto to connect as the ASP.Net process account. (Such as IWAM_machine). You will need to figure out what process your ASP.NET web app runs under and then configure that user with a SQL Server login and access to the database. Alternatively, you can substitute username= and pwd= to specify a SQL Server username and password. This is a less secure method.

<add key="DefaultTheme" value="simplegrey\" />
The folder name, including trailing slash, of the theme you want to be used by default.

<add key="ThemeAbsPath" value="f:\lasto\themes\" />
The physical path of your theme files, such as c:\inetpub\wwwroot\lasto\themes\. Includes trailing slash.

<add key="URLPath" value="http://www.stuff.com/forums/" />
URL Path to Lasto - this will be used in theme files and emails. Include trailing forward slash.

<add key="ErrorLogFilename" value="f:\lastologs\error.log" />
Path to a file where Lasto can write error logs. Please note that you should probably make this a folder that is NOT in your web root since the account Lasto runs under needs Write access to that folder. If you are forced to keep the folder under your web root, take away read access and set Execute to none. If you leave this blank or set it to an invalid path, when unexpected errors are encountered they will be lost and will not be written to the log.

<add key="MailServer" value="192.168.0.150" />
IP address of the SMTP mail server Lasto should use to send emails. Use 127.0.0.1 if you have SMTP setup on the local web server. Whatever machine it is, it must allow relaying from the webserver.

<add key="Themes" value="simplegrey`Simple Grey;easyblue`Easy Blue;notsogrey`Not So Grey;ancientblue`Ancient Blue;pocketpc`PocketPC or Text Only;" />
This sets up what themes to use. The field is composed of records, each terminated by a semicolon. Each record has two fields, separated by a backtick. For example, here is a record: folder`Themename;

The first field is the folder name (without any slashes or path) where the theme resides under Themes\. The second field is the display name.

<add key="MaxImgSize" value="60000" />
This is the maximum size, in bytes, of images that may be uploaded using the image feature. Use this to control database size.

<add key="MaxImgCount" value="5" />
This is the maximum number of images any specific user may have in the database at any one time. Use this in combination with MaxImgSize to control database growth. For example, if you have 1000 users, and you allow each user to store 10 pictures of 50,000 bytes each, you could have a maximum database size of ~475 megabytes to hold the pictures. This is just an upper limit, and in practice not all your users will fill up all their image slots and some may not upload any.

These settings are just the global restrictions; you may grant or deny the ability to upload images on a per-user and per-group basis to further control the use.

<add key="ExpireImgDays" value="30" />
This is how many days an image is allowed to "live" in the database before being automatically deleted. You can set this to a really high number like 36500 (100 years) to effectively turn it off. Or you can set it to a short time period to control database size.

Note that this is not a promise that an image WILL be deleted when it reaches this age, merely that an image can be assured of reaching this age without being deleted. This is because image deletes are run when someone uploads a new image to the database. So in theory, if an image were uploaded and passed this setting and no one else ever uploaded a new image, the delete job would never run.

<add key="RequireImgRef" value="1" />
If this is set to 1, then images will only be displayed if the referrer header contains URLPath within it. If that header is not found or does not contain URLPath the image will not be displayed.

You can use this to prevent image leeching from other sites which would waste your bandwidth. However if you wish to provide image hosting as a premium service you may choose to turn this off and let users post their uploaded images anywhere.

<add key="enckey" value="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" />
This is the Triple-DES encoding key. Be sure to generate a new random key for your own site before you "go live".

<add key="enciv" value="BBBBBBBBBBB=" />
This is the Triple-DES initialization vector. Be sure to generate a new one before you "go live".

</appSettings>
</configuration>

That's all there is to it! Anytime you make changes to web.config (either via the filesystem or by FTPing up the new file), Lasto will be reloaded and the settings will be picked up. There is no need to restart IIS or the webserver.

If the web.config file is incorrect or contains errors, you should get an ASP.NET error message telling you what is wrong with it. However if you are on shared hosting and the service provide has turned off client reporting of errors for the whole machine, you will need to contact them or get a local logon to examine the error in more detail.