ممنون جناب نصیری. سایت tvagile.com هم ویدئو های آموزشی خوبی راجع به اسکرام منتشر می کند که دیدن آنها خالی از لطف نیست.
موفق باشید
موفق باشید
نظرات نظرسنجی‌ها
آیا با وجود سی‌ام‌اس فروشگاهی قدرتمندی مثل nopCommerce یا SmartStore آیا منطقی است که ما دوباره خودمان از صفر کد بزنیم؟
بنظرم در بین اینها گزینه ووکامرس خالی هست . طبق آمار سایت wappalyzer بیشترین استفاده رو برای برپایی سایتهای فروشگاهی دارد . البته یک پلاگین از CMS محبوب وردپرس هست.
- در سازنده‌ی کلاس ApplicationDbContext ، به connectionString1 اشاره شده که تعریف آن در فایل web.config برنامه موجود است. به عبارتی در این مثال چنین رشته‌ی اتصالی تعریف شده‌است:
بنابراین بانک اطلاعاتی پیش فرض آن TestDbIdentity نام دارد (جهت اتصال به آن، برای مشاهده جداول و یا تغییر و ثبت اطلاعات). این رشته اتصالی هم مخصوص SQL Server تنظیم شده‌است که میتوانید توسط management studio و یا سایر ابزارهای مشابه، همانند قبل به آن متصل شوید.
- «در پوشه App_Data حذف کردم» ... از مثال نهایی کامل شده استفاده کنید (^) و نیازی به تکرار این مراحل نیست تا خطای یافت نشدن dbcontext را دریافت نکنید.
- برای ReCreate فقط کافی هست که بانک اطلاعاتی TestDbIdentity را drop کنید. بعد برنامه را مجددا از نو اجرا کنید. چون مراحل migrations آن به حالت خودکار تنظیم شده‌است، بانک اطلاعاتی را به صورت خودکار ایجاد می‌کند یا تغییرات کلاس‌های دومین برنامه را به صورت خودکار به بانک اطلاعاتی اعمال خواهد کرد.
- برای آشنایی بیشتر با مباحث تعریف رشته اتصالی EF Code First و مباحث Migrations آن، سری EF Code First را در سایت یکبار مطالعه کنید.
<add name="connectionString1" connectionString="Data Source=(local);Initial Catalog=TestDbIdentity;Integrated Security = true" providerName="System.Data.SqlClient" />
- «در پوشه App_Data حذف کردم» ... از مثال نهایی کامل شده استفاده کنید (^) و نیازی به تکرار این مراحل نیست تا خطای یافت نشدن dbcontext را دریافت نکنید.
- برای ReCreate فقط کافی هست که بانک اطلاعاتی TestDbIdentity را drop کنید. بعد برنامه را مجددا از نو اجرا کنید. چون مراحل migrations آن به حالت خودکار تنظیم شده‌است، بانک اطلاعاتی را به صورت خودکار ایجاد می‌کند یا تغییرات کلاس‌های دومین برنامه را به صورت خودکار به بانک اطلاعاتی اعمال خواهد کرد.
- برای آشنایی بیشتر با مباحث تعریف رشته اتصالی EF Code First و مباحث Migrations آن، سری EF Code First را در سایت یکبار مطالعه کنید.
سی‌شارپ نیز مانند بسیاری از زبان‌های شیءگرای دیگر، امکان فیلتر کردن استثناءها را بر اساس نوع آنها، دارا است. برای مثال:
در اینجا میتوان بر اساس نوع استثنای مدنظر، چندین catch را نوشت و مدیریت کرد. اما گاهی از اوقات شاید بهتر باشد بجای مدیریت کلی یک نوع از استثناءها، فقط نوعی خاص را صرفا بر اساس شرایطی مشخص، مدیریت کرد. این قابلیت، تحت عنوان Exception Filtering به C# 6 اضافه شده‌است و شکل کلی آن به صورت ذیل است:
در این حالت ابتدا نوع استثناء بررسی میشود و سپس شرطی که در قسمت when ذکر شده‌است. اگر هر دو با هم برقرار بودند، آنگاه این استثنای خاص مدیریت خواهد شد؛ در غیر اینصورت، از مدیریت این نوع استثناء صرفنظر می‌گردد. این قابلیت، از ابتدای ارائه‌ی CLR وجود داشته‌است، اما C#6 تازه شروع به استفاده‌ی از آن کرده‌است (و VB.NET از چند نگارش قبل).
علاوه بر این در اینجا میتوان چندین بدنه‌ی catch مجزا را به ازای یک نوع استثنای مشخص به همراه whenهای متفاوتی نیز تعریف کرد و از این لحاظ محدودیتی وجود ندارد. فقط در این حالت باید به تقدم و تاخرها دقت داشت. برای نمونه در مثال ذیل، ترکیب چندین شرط متفاوت را بر اساس یک نوع مشخص استثناء، مشاهده میکنید. در اینجا اگر برای نمونه شرط ذکر شده‌ی در قسمت when مربوط به catch اولی صادق باشد، همینجا کار خاتمه می‌یابد و سایر catchها بررسی نمی‌شوند:
مورد آخر، حالت catch all را دارد و در صورت شکست دو catch قبلی اجرا میشود. اما باید دقت داشت که اگر این catch all بدون شرط و بدون قسمت when را در ابتدا ذکر کنیم، دیگر کار به بررسی سایر catchهای این نوع استثنای خاص نخواهد رسید:
در مثال فوق هیچگاه دو catch تعریف شده‌ی پس از catch all اولی اجرا نمی‌شوند.
لاگ کردن استثناءها در C# 6 بدون مدیریت آنها
به مثال ذیل دقت کنید:
در قسمت when میتوان هر متدی که true یا false را برگرداند، فراخوانی کرد. در این مثال، متدی تعریف شده‌است که false بر می‌گرداند. یعنی این استثناء کلی از نوع Exception هرچند به ظاهر دارای قسمت when است و مدیریت شده‌است، اما چون خروجی متد Log قسمت when آن مساوی false است، مدیریت نخواهد شد. یعنی در اینجا میتوان بدون مدیریت یک استثناء، اطلاعات کامل آن‌را لاگ کرد!
تفاوت C# 6 - Exception Filtering با if/else نوشتن در بدنه‌ی catch چیست؟
تا اینجا به این نتیجه رسیدیم که کدهای if/else دار داخل بدنه‌ی catch کدهای قدیمی را مانند کد ذیل:
میتوان به شکل جدید C# 6 به همراه when نوشت و تبدیل کرد:
اما باید دقت داشت که تفاوت مهم قطعه کد دوم، در مباحث Stack unwinding است. در مثال اولی که if/else داخل بدنه‌ی catch نوشته شده‌است، اطلاعات local محل فراخوانی متدی را که سبب بروز استثناء شده‌است، از دست خواهیم داد؛ اما در مثال دوم خیر.
به این معنا که exception filters سبب Stack unwinding نمی‌شوند. با هربار ورود به بدنه‌ی catch، اصطلاحا عملیات Stack unwinding صورت می‌گیرد. یعنی اطلاعات stack مربوط به متدهای پیش از فراخوانی متدی که سبب بروز استثناء شده‌است، از بین می‌روند. به این ترتیب تشخیص مقادیر متغیرهایی که سبب بروز این استثناء شده‌اند نیز میسر نخواهد بود و دیگر نمیتوان با قطعیت عنوان کرد که چه مقادیری و چه اطلاعاتی سبب بروز این مشکل شده‌اند. اما در حالت exception filters در قسمت when آن هنوز وارد بدنه‌ی catch نشده‌ایم. در اینجا دسترسی کاملی به اطلاعات stack جاری و مقادیر متغیرهای محلی که سبب بروز این استثناء شده‌اند وجود دارد.
تفاوت stack با stack trace چیست؟ stack قطعه‌ای از حافظه‌است که اطلاعاتی در مورد نحوه‌ی فراخوانی متدها، آدرس بازگشتی آنها، آرگومان و همچنین متغیرهای محلی آنها را دارا است. اما stack trace تنها یک رشته‌است و بیانگر نام متدهایی است که هم اکنون بر روی stack قرار دارند. احتمالا پیشتر خوانده بودید که فراخوانی throw داخل بدنه‌ی catch سبب حفظ stack trace میشود و اگر throw ex صورت گیرد، این اطلاعات از دست می‌روند و بازنویسی می‌شوند. اما در C# 6 امکان حفظ کل اطلاعات stack به همراه exception filtering میسر شده‌است.
try
{
// some code to check ...
}
catch (InvalidOperationException ex)
{
// do your handling for invalid operation ...
}
catch (IOException ex)
{
// do your handling for IO error ...
} catch (SomeException ex) when (someConditionIsMet)
{
// Your handler logic
} علاوه بر این در اینجا میتوان چندین بدنه‌ی catch مجزا را به ازای یک نوع استثنای مشخص به همراه whenهای متفاوتی نیز تعریف کرد و از این لحاظ محدودیتی وجود ندارد. فقط در این حالت باید به تقدم و تاخرها دقت داشت. برای نمونه در مثال ذیل، ترکیب چندین شرط متفاوت را بر اساس یک نوع مشخص استثناء، مشاهده میکنید. در اینجا اگر برای نمونه شرط ذکر شده‌ی در قسمت when مربوط به catch اولی صادق باشد، همینجا کار خاتمه می‌یابد و سایر catchها بررسی نمی‌شوند:
catch (SomeDependencyException ex) when (condition1 && condition2)
{
}
catch (SomeDependencyException ex) when (condition1)
{
}
catch (SomeDependencyException ex)
{
} catch (SomeDependencyException ex)
{
}
catch (SomeDependencyException ex) when (condition1 && condition2)
{
}
catch (SomeDependencyException ex) when (condition1)
{
} لاگ کردن استثناءها در C# 6 بدون مدیریت آنها
به مثال ذیل دقت کنید:
try
{
DoSomethingThatMightFail(s);
}
catch (Exception ex) when (Log(ex, "An error occurred"))
{
// this catch block will never be reached
}
...
static bool Log(Exception ex, string message, params object[] args)
{
Debug.Print(message, args);
return false;
} تفاوت C# 6 - Exception Filtering با if/else نوشتن در بدنه‌ی catch چیست؟
تا اینجا به این نتیجه رسیدیم که کدهای if/else دار داخل بدنه‌ی catch کدهای قدیمی را مانند کد ذیل:
try
{
var request = WebRequest.Create("http://www.google.coom/");
var response = request.GetResponse();
}
catch (WebException we)
{
if (we.Status == WebExceptionStatus.NameResolutionFailure)
{
//handle DNS error
return;
}
if (we.Status == WebExceptionStatus.ConnectFailure)
{
//handle connection error
return;
}
throw;
} try
{
var request = WebRequest.Create("http://www.google.coom/");
var response = request.GetResponse();
}
catch (WebException we) when (we.Status == WebExceptionStatus.NameResolutionFailure)
{
//Handle NameResolutionFailure Separately
}
catch (WebException we) when (we.Status == WebExceptionStatus.ConnectFailure)
{
//Handle ConnectFailure Separately
} به این معنا که exception filters سبب Stack unwinding نمی‌شوند. با هربار ورود به بدنه‌ی catch، اصطلاحا عملیات Stack unwinding صورت می‌گیرد. یعنی اطلاعات stack مربوط به متدهای پیش از فراخوانی متدی که سبب بروز استثناء شده‌است، از بین می‌روند. به این ترتیب تشخیص مقادیر متغیرهایی که سبب بروز این استثناء شده‌اند نیز میسر نخواهد بود و دیگر نمیتوان با قطعیت عنوان کرد که چه مقادیری و چه اطلاعاتی سبب بروز این مشکل شده‌اند. اما در حالت exception filters در قسمت when آن هنوز وارد بدنه‌ی catch نشده‌ایم. در اینجا دسترسی کاملی به اطلاعات stack جاری و مقادیر متغیرهای محلی که سبب بروز این استثناء شده‌اند وجود دارد.
تفاوت stack با stack trace چیست؟ stack قطعه‌ای از حافظه‌است که اطلاعاتی در مورد نحوه‌ی فراخوانی متدها، آدرس بازگشتی آنها، آرگومان و همچنین متغیرهای محلی آنها را دارا است. اما stack trace تنها یک رشته‌است و بیانگر نام متدهایی است که هم اکنون بر روی stack قرار دارند. احتمالا پیشتر خوانده بودید که فراخوانی throw داخل بدنه‌ی catch سبب حفظ stack trace میشود و اگر throw ex صورت گیرد، این اطلاعات از دست می‌روند و بازنویسی می‌شوند. اما در C# 6 امکان حفظ کل اطلاعات stack به همراه exception filtering میسر شده‌است.
بازخوردها و خطاها پس از نصب :
بنده سرور مجازی 2008 رو مورد آزمایش قرار دادم :
با خطای 502.5 مواجه شدم
و تغییری که در فایل webconfig جهت log کردن انجام دادم مورد زیر از توضیحات بالا مشاهده شد :
ASP.NET Core Module Log: Log file created but empty
که پس از Restart ویندوز سرور - مشکل خالی بودن فایل‌های لاگ برطرف شد و اینبار در فایل‌های لاگ با متن خطای زیر مواجه شدم:
Failed to load the dll from [C:\Program Files\dotnet\host\fxr\1.0.1\hostfxr.dll], HRESULT: 0x80070057
در حال حاضر در صدد رفع این مشکل هستم.
بنده سرور مجازی 2008 رو مورد آزمایش قرار دادم :
با خطای 502.5 مواجه شدم
که طبق نکاتی که در لینک پایین تصویر وجود داشت :
Hosting bundle not installed or server not restarted
- Browser: 502.3 Bad Gateway: There was a connection error while trying to route the request.
- Application Log: Process ‘0’ failed to start. Port = PORT, Error Code = ‘-2147024894’.
- ASP.NET Core Module Log: Log file created but empty
و تغییری که در فایل webconfig جهت log کردن انجام دادم مورد زیر از توضیحات بالا مشاهده شد :
ASP.NET Core Module Log: Log file created but empty
که پس از Restart ویندوز سرور - مشکل خالی بودن فایل‌های لاگ برطرف شد و اینبار در فایل‌های لاگ با متن خطای زیر مواجه شدم:
Failed to load the dll from [C:\Program Files\dotnet\host\fxr\1.0.1\hostfxr.dll], HRESULT: 0x80070057
در حال حاضر در صدد رفع این مشکل هستم.
یکی از کارهایی که Googlebot و سایر خزنده‌های انواع و اقسام جستجوگرها انجام می‌دهند، سرک کشیدن به لینک‌هایی است که در صفحه قرار گرفته‌اند. اگر سایت شما از SiganlR استفاده کند، به طور قطع یک چنین تعریفی را خواهد داشت:
فراخوانی‌های نابجای این آدرس سبب خواهد شد تا علاوه بر بروز استثناهای اضافی لاگ شده در سمت سرور، اتصالاتی ماندگار نیز ایجاد شوند تا کلاینت و سرور بتوانند کار bidirectional communication را انجام دهند. برای رفع این مشکل تنها کافی است در فایل robots.txt سایت، مسیر یاد شده را ممنوعه اعلام کنید:
<script src="signalr/hubs" type="text/javascript"></script>
User-agent: * Disallow: /signalr/
مطالب بالا رو مطالعه کردم اما جواب سوالم را نتوانستم پیدا کنم.
دیتابیس‌ها من کاملا جدا از هم و از سیستم‌های جداگانه هستن و نیاز به رد و بدل اطلاعات دارند.
من چگونه می‌توانم تزریق وابستگی را انجام دهم؟
دیتابیس‌ها من کاملا جدا از هم و از سیستم‌های جداگانه هستن و نیاز به رد و بدل اطلاعات دارند.
من چگونه می‌توانم تزریق وابستگی را انجام دهم؟
Linq2Sql که خیلی وقت هست با EF جایگزین شده. EF هم از نوع‌های خاص دیتابیس‌ها عموما پشتیبانی نمی‌کنه. بحث EF هم نیست. اکثر ORMهای موجود همینطور هستند.
انواع داده‌ها، جنبه‌ی ضروری هر زبان برنامه نویسی هستند و Rust نیز از این قاعده مستثنا نیست. در Rust از انواع داده برای تعریف نوع داده‌ای که یک متغیر میتواند نگه دارد استفاده میشود. این مقاله رایج‌ترین انواع داده در Rust را پوشش میدهد، از جمله:
Boolean
در Rust، نوع داده بولین با کلمه کلیدی bool نشان داده میشود. این نوع داده، فقط میتواند دو مقدار داشته باشد: true یا false و معمولاً در دستورات شرطی و حلقه‌ها برای کنترل جریان یک برنامه استفاده میشود.
Unsigned int
اعداد صحیح بدون علامت در Rust با کلمه کلیدی u و سپس تعداد بیت‌هایی که عدد صحیح باید داشته باشد، نشان داده می‌شوند. به عنوان مثال، u8 یک عدد صحیح بدون علامت 8 بیتی را نشان میدهد. محدوده‌ی یک عدد صحیح بدون علامت از 0 تا 2^n - 1 است که n تعداد بیت‌ها است.
Signed int
اعداد صحیح علامت‌دار در Rust با کلمه‌ی کلیدی i و سپس تعداد بیت‌هایی که عدد صحیح باید داشته باشد، نشان داده می‌شوند. به عنوان مثال، i32، یک عدد صحیح علامت‌دار 32 بیتی را نشان میدهد. محدوده یک عدد صحیح علامت‌دار از -2^(n-1) تا 2^(n-1) - 1 است که n تعداد بیت‌ها است.
Floating point numbers
اعداد ممیز شناور در Rust با کلمات کلیدی f32 یا f64 نشان داده می‌شوند که به ترتیب مخفف اعداد ممیز شناور 32 بیتی و 64 بیتی هستند. این نوع داده‌ها برای نمایش اعداد واقعی با اعشار استفاده می‌شوند.
Char
نوع داده char در Rust، نشان دهنده یک کاراکتر یونیکد است؛ برخلاف رشته‌هایی که با گیومه‌های دوتایی (") نشان داده می‌شوند.
String types
در Rust دو نوع رشته وجود دارد: String و str. نوع String، یک نوع رشته‌ای heap-allocated و قابل رشد است؛ در حالیکه str (تلفظ "string slice") یک نوع رشته‌ای است که به یک برش از یک رشته در حافظه اشاره می‌کند:
Arrays
آرایه‌ها در Rust، مجموعه‌هایی با اندازه‌ی ثابت از عناصر از یک نوع هستند. آنها با براکت مربع ([]) و نوع عناصر داخل آرایه نشان داده می‌شوند.
Tuples
تاپل‌ها در Rust، مجموعه‌ای از عناصر از انواع مختلف هستند. آنها با پرانتز (()) و انواع عناصر داخل تاپل نشان داده می‌شوند.
Type aliasing
تایپ aliasing در Rust، به شما امکان میدهد تا نام جدیدی را به یک نوع موجود بدهید. این میتواند برای خوانایی بیشتر کد یا ساده کردن انواع پیچیده مفید باشد.
- Boolean
- Unsigned int
- Signed int
- Floating point numbers
- Char
- String types
- Arrays
- Tuples
- Type aliasing
Boolean
در Rust، نوع داده بولین با کلمه کلیدی bool نشان داده میشود. این نوع داده، فقط میتواند دو مقدار داشته باشد: true یا false و معمولاً در دستورات شرطی و حلقه‌ها برای کنترل جریان یک برنامه استفاده میشود.
let is_rust_awesome: bool = true;
Unsigned int
اعداد صحیح بدون علامت در Rust با کلمه کلیدی u و سپس تعداد بیت‌هایی که عدد صحیح باید داشته باشد، نشان داده می‌شوند. به عنوان مثال، u8 یک عدد صحیح بدون علامت 8 بیتی را نشان میدهد. محدوده‌ی یک عدد صحیح بدون علامت از 0 تا 2^n - 1 است که n تعداد بیت‌ها است.
let x: u8 = 255;
Signed int
اعداد صحیح علامت‌دار در Rust با کلمه‌ی کلیدی i و سپس تعداد بیت‌هایی که عدد صحیح باید داشته باشد، نشان داده می‌شوند. به عنوان مثال، i32، یک عدد صحیح علامت‌دار 32 بیتی را نشان میدهد. محدوده یک عدد صحیح علامت‌دار از -2^(n-1) تا 2^(n-1) - 1 است که n تعداد بیت‌ها است.
let x: i32 = -2147483648;
Floating point numbers
اعداد ممیز شناور در Rust با کلمات کلیدی f32 یا f64 نشان داده می‌شوند که به ترتیب مخفف اعداد ممیز شناور 32 بیتی و 64 بیتی هستند. این نوع داده‌ها برای نمایش اعداد واقعی با اعشار استفاده می‌شوند.
let x: f32 = 3.14;
Char
نوع داده char در Rust، نشان دهنده یک کاراکتر یونیکد است؛ برخلاف رشته‌هایی که با گیومه‌های دوتایی (") نشان داده می‌شوند.
let c: char = 'a';
String types
در Rust دو نوع رشته وجود دارد: String و str. نوع String، یک نوع رشته‌ای heap-allocated و قابل رشد است؛ در حالیکه str (تلفظ "string slice") یک نوع رشته‌ای است که به یک برش از یک رشته در حافظه اشاره می‌کند:
let s1: String = String::from("hello");
let s2: &str = "world"; Arrays
آرایه‌ها در Rust، مجموعه‌هایی با اندازه‌ی ثابت از عناصر از یک نوع هستند. آنها با براکت مربع ([]) و نوع عناصر داخل آرایه نشان داده می‌شوند.
let arr: [i32; 5] = [1, 2, 3, 4, 5];
Tuples
تاپل‌ها در Rust، مجموعه‌ای از عناصر از انواع مختلف هستند. آنها با پرانتز (()) و انواع عناصر داخل تاپل نشان داده می‌شوند.
let tup: (i32, f64, u8) = (500, 6.4, 1);
Type aliasing
تایپ aliasing در Rust، به شما امکان میدهد تا نام جدیدی را به یک نوع موجود بدهید. این میتواند برای خوانایی بیشتر کد یا ساده کردن انواع پیچیده مفید باشد.
type Age = u32; let age: Age = 30;
پیکربندی قسمت لاگها، میتواند برای یک سرور و یا وب سایت خاص از طریق فایل کانفیگ یا از طریق خود IIS انجام گیرد. برای اینکه به بیشتر این قابلیت‌ها در IIS دسترسی داشت، باید یکی از نسخه‌های ویندوز سرور 2012 و ویندوز 8 را نصب کرده باشید. لاگها به ثبت خطاها و درخواست‌های HTTP می‌پردازند و با تحلیل آنها میتوان عملیات بهینه سازی را بر روی سرو اجرا کرد. تمامی ثبت لاگها توسط Http.sys انجام می‌گیرد.
نحوه‌ی ذخیره سازی لاگها
در این بخش نحوه‌ی ذخیره سازی و فرمت ذخیره‌ی لاگها را در دو سطح سایت و سرور به طور جداگانه بررسی می‌کنیم. در IIS ماژول Logging را باز کنید و در لیست One log file per میتوانید مشخص کنید که لاگها در چه سطحی اجرا شوند. اگر گزینه‌ی server باشد، تمامی خطاها و درخواست‌های رسیده به سرور در یک فایل لاگ ثبت می‌شوند. ولی اگر سطح سایت باشد، برای هر سایت بر روی IIS لاگها، جداگانه بررسی می‌شوند. به طور پیش فرض سطح سایت انتخاب شده است.
سطح سایت
موقعی‌که در لیست، سایت را انتخاب کنید، در لیست format میتوانید تعیین کنید که لاگها به چه صورتی باید ذخیره شوند. مواردی که در این حالت لیست می‌شوند گزینه‌های W3C,IIS,NCSA,Custom می‌باشند که در زیر یکایک آنها را بررسی می‌کنیم:
فرمت IIS: این فرمت توسط مایکروسافت ارائه شده و در این حالت لاگ‌های همه‌ی وب سایت‌ها ذخیره می‌شوند. به این فرمت Fixed ASCII Based Text نیز می‌گویند؛ چرا که اجازه‌ی خصوصی سازی ندارد و نمی‌توانید بگویید چه فیلدهایی در لاگ قرار داشته باشند. لاگ فایل‌های این فرمت با ، (کاما) از هم جدا می‌شوند و مقدار زمانی که برای هر فیلد ثبت میشود، به صورت محلی local Time می‌باشد.
فیلدهایی که در لاگ این نوع فرمت خواهند آمد، به شرح زیر است:
- Client IP address
- User name
- Date
- Time
- Service and instance
- Server name
- Server IP address
- Time taken
- Client bytes sent
- Server bytes sent
- (Service status code (A value of 200 indicates that the request was fulfilled successfully
- (Windows status code (A value of 0 indicates that the request was fulfilled successfully.
- Request type
- Target of operation
- (Parameters (the parameters that are passed to a script
احتمال این وجود دارد که بعضی از فیلدها در بعضی رکوردها، شامل اطلاعاتی نباشند که به جای مقدار آن علامت - ثبت می‌گردد و برای کاراکترهایی که قابل نمایش نیستند یا کاراکتر نمایشی ندارند، از علامت + استفاده میشود. دلیل اینکار هم این است که ممکن است یک کاربر مهاجم، به ارسال اطلاعات کلیدهای کنترلی چون Carriage return اختصارا CR یا Line Feed به اختصار LF کند، که باعث شکسته شدن خط لاگ فایل میشود و در نتیجه از استاندارد خارج خواهد شد و هنگام خواندن آن هم با خطا روبرو میشویم؛ در نتیجه با جایگزینی چنین کاراکترهایی با + از این اتفاق جلوگیری میشود.
شکل زیر نمونه ای از یک خط لاگ در این فرمت است:
192.168.114.201, -, 03/20/01, 7:55:20, W3SVC2, SERVER, 172.21.13.45, 4502, 163, 3223, 200, 0, GET, /DeptLogo.gif, -,
| نام فیلد | نوع حالت مقداردهی | توضیح اتفاقات افتاده | |
| Client IP address | 192.168.114.201 | آی پی کلاینت | |
| User name | - | کاربر ناشناس است | |
| Date | 03/20/01 | تاریخ فعالیت | |
| Time | 7:55:20 | ساعت فعالیت | |
| Service and instance | W3SVC2 | لاگی که مربوط به سایت خاصی میشود به صورت #W3SVC نمایش داده میشود که علامت # شماره سایت می‌باشد که در اینجا این لاگ مربوط به سایت شماره 2 است | |
| Server name | SERVER | نام سرور | |
| Server IP | 172.21.13.45 | آی پی سرور | |
| Time taken | 4502 | چقدر انجام عملیات این درخواست به طول انجامیده است که بر حسب میلی ثانیه است. | |
| Client bytes sent | 163 | تعداد بایت هایی که از طرف کلاینت به سرور ارسال شده است | |
| Server bytes sent | 3223 | تعداد بایت هایی که از طرف سرور به سمت کلاینت ارسال شده است | |
| Service status code | 200 | درخواست کاملا موفقیت آمیز بوده است | |
| Windows status code | 0 | درخواست کاملا موفقیت آمیز بوده است | |
| Request type | GET | نوع درخواست کاربر | |
| Target of operation | /DeptLogo.gif | کاربر قصد دانلود یک فایل تصویری GIF داشته است که نامش Deptlogo است | |
| Parameters | - | پارامتری ارسال نشده است |
فرمت NCSA: این فرمت توسط مرکز علمی کاربردهای ابرمحاسباتی National Center for Supercomputing Applications ایجاد شده و دقیقا مانند قبلی نمیتوان در آن نوع فیلدها را مشخص کرد و برای جدا سازی، از فاصله space استفاده می‌کند و ثبت مقدار زمان در آن هم به صورت محلی و هم UTC می‌باشد.
این فیلدها در لاگ آن نمایش داده می‌شوند:
- Remote host address
- (Remote log name (This value is always a hyphen
- User name
- Date, time, and Greenwich mean time (GMT) offset
- Request and protocol version
- (Service status code (A value of 200 indicates that the request was fulfilled successfully
- Bytes sen
نمونه ای از یک لاگ ثبت شده:
172.21.13.45 - Microsoft\JohnDoe [08/Apr/2001:17:39:04 -0800] "GET /scripts/iisadmin/ism.dll?http/serv HTTP/1.0" 200 3401
| نام فیلد | مقدار ثبت شده | توضیح اتفاق افتاده |
| Remote host address | 172.21.13.45 | آی پی کلاینت |
| Remote log name | - | نامی وجود ندارد |
| User name | Microsoft\JohnDoe | نام کاربری |
| Date, time, and GMT offset | [08/Apr/2001:17:39:04 -0800] | تاریخ و ساعت فعالیت به صورت محلی که 8 ساعت از مبدا گرینویچ بیشتر است |
| Request and protocol version | GET /scripts/iisadmin/ism.dll?http/serv HTTP/1.0 | کاربر با متد GET و Http نسخه‌ی یک، درخواست فایل ism.dll را کرده است. |
| Service status code | 200 | عملیات کاملا موفقیت آمیز بود. |
| Bytes sent | 3401 | تعداد بایت‌های ارسال شده به سمت کاربر |
امنیت در برابر کاربران مهاجم مانند همان فرمت قبلی صورت گرفته است.
فرمت W3C: توسط W3C توسط کنسرسیوم جهانی وب ارائه شده است و یک فرمت customizable ASCII text-based است. به این معنی که میتوان فیلدهایی که در گزارش نهایی می‌آید را خودتان مشخص کنید، که برای اینکار در کنار لیست، دکمه‌ی Select وجود دارد که میتوانید هر کدام از فیلدهایی را که خواستید، انتخاب کنید تا به ترتیب در خط لاگ ظاهر شوند. تاریخ ثبت به صورت UTC است.
| نام فیلد | توضیح | به طور پیش فرض انتخاب شده است |
| Date | تاریخ رخ دادن فعالیت | بله |
| Time | ساعت زخ دادن فعالیت بر اساس UTC | بله |
| Client IP Address | آی پی کلاینت | بله |
| User Name | نام کاربری که هویت آن تایید شده و در صورتی که هویت تایید شده نباشد و کاربر ناشناس باشد، جای آن - قرار می‌گیرد | بله |
| Service Name and Instance Number | نام و شماره سایتی که درخواست در آن صورت گرفته است | خیر |
| Server Name | نام سروری که لاگ روی آن ثبت میشود | خیر |
| Server IP Address | آی پی سرور که لاگ روی آن ثبت میشود | بله |
| Server Port | شمره پورتی که سرویس مورد نظر روی آن پورت اعمال میشود. | بله |
| Method | متد درخواست مثل GET | بله |
| URI Stem | هدف درخواست یا Target مثل index.htm | بله |
| URI Query | کوئری ارسال شده برای صفحات داینامیک | بله |
| HTTP Status | کد وضیعینی HTTP status | بله |
| Win32 Status | کد وضعیتی ویندوز | خیر |
| Bytes Sent | تعداد بایت‌های ارسال شده به سمت کلاینت | خیر |
| Bytes Received | تعداد بایت‌های دریافت شده از سمت کلاینت | خیر |
| Time Taken | زمان به طول انجامیدن درخواست بر حسب میلی ثانیه | خیر |
| Protocol Version | درخواست با چه نسخه‌ای از پروتکل http یا ftp ارسال شده است | خیر |
| Host | اگر در هدر درخواست ارسالی این گزینه بوده باشد، نوشته خواهد شد. | خیر |
| User Agent | اطلاعات را از هدر درخواست می‌گیرد. | بله |
| Cookie | اگر کوکی رد و بدل شده باشد، محتویات کوکی ارسالی یا دریافت شده | خیر |
| Referrer | کاربر از چه سایتی به سمت سایت ما آمده است. | خیر |
| Protocol Substatus | در صورت رخ دادن خطا در IIS ، کد خطا بازگردانده میشود. در IIS به منظور امنیت بیشتر و کاهش حملات، محتوای خطاهای رخ داده در IIS به صورت متنی نمایش داده نمی‌شوند و شامل کد خطایی به اسم Substatus Code هستند تا مدیران شبکه با ردیابی لاگها پی به دلیل خطا و درخواست‌های ناموفق ببرند. برای مثال Error 404.2 به این معنی است که فایل درخواستی به دلیل قوانین محدود کنده، قفل شده و قابل ارائه نیست. ولی هکر تنها با خطای 404 یعنی وجود نداشتن فایل روبرو میشود. در حالت substatus code، کد شماره 2 را هم خواهید داشت که در لاگ ثبت میشود. هر شخصی که در سرور توانایی دسترسی به لاگها را داشته باشد، میتواند کد دوم خطا را نیز مشاهده کند. برای مثال مدیر سرور متوجه میشود که یکی از فایل‌های مورد نظر به کاربران، خطای 404 نمایش میدهد و با بررسی لاگها متوجه میشود که کد خطا 404.9 هست. از آنجا که ما همه‌ی کدها را حفظ نیستیم به این صفحه رجوع می‌کنیم و متوجه میشویم تعداد کاربرانی که برای این فایل، اتصال connection ایجاد کرده‌اند بیش از مقدار مجاز است و مدیر میتواند این وضع را کنترل کند. برای مثال تعداد اتصالات مجاز را نامحدود unlimited تعیین کند. | بله |
- uri-query
- host
- (User-Agent)
- Cookie
- Referrer
- substatus
گزینه Custom : موقعی که شما این گزینه را انتخاب کنید ماژول logging غیرفعال خواهد شد. زیرا این امکان در IIS قابل پیکربندی نیست و نوشتن ماژول آن بر عهده شما خواهد بود؛ با استفاده از اینترفیس های ILogPlugin ، ILogPluginEx و ILogUIPlugin آن را پیاده سازی کنید.
ذخیره اطلاعات به انکدینگ UTF-8 و موضوع امنیت
در صورتی که شما از سایتی با زبانی غیر از انگلیسی و لاتین و فراتر از ANSI استفاده میکنید، این گزینه حتما باید انتخاب شده باشد تا درخواست را بهتر لاگ کند. حتی برای وب سایتهای انگلیسی زبان هم انتخاب این گزینه بسیار خوب است؛ چرا که اگر به سمت سرور کاراکترهای خاصی در URL ارسال شوند، نمی‌تواند با کدپیج موجود آنها را درست تبدیل کند.
ادامه‌ی تنظیمات
موارد بعدی که در تنظیمات لاگها کاملا مشخص و واضح است، عملیات زمان بندی است که برای ساخت یک فایل لاگ جدید به کار می‌رود؛ برای مثال هر ساعت یک لاگ فایل جدید بسازد و فعالیت‌های موجود در هر ساعت در یک لاگ ذخیره می‌شوند.
گزینه‌ی بعدی حداکثر حجم هر فایل لاگ است که به صورت بایت مشخص میشود. اگر مقداری که تعیین میکنید کمتر از 1048576 بایت باشد، خودش به طور پیش فرض همان 1048576 بایت را در نظر خواهد گرفت.
گزینه بعدی do not create a new logfile بدین معناست که همه‌ی لاگها در یک فایل ذخیره می‌شوند و فایل جدیدی برای لاگها ایجاد نمی‌شود.
گزینه آخری به اسم use local time for filenaming and rollover است که اگر انتخاب شود، نامگذاری هر فایل لاگ بر اساس زمان محلی ساخت فایل لاگ خواهد بود. در صورتیکه انتخاب نشود، نامگذاری با زمان UTC درج خواهد شد.
سطح سرور
لاگها فقط در سمت سرور انجام می‌گیرد و لاگ هر سایت در یک فایل لاگ ثبت میشود. اگر بخواهید لاگها را در سطح سرور انجام دهید، گزینه‌ی binary هم اضافه خواهد شد.
Binary: در این گزینه دیگر از قالب بندی یا فرمت بندی لاگها خبری نیست و لاگ هر وب سایت به صورت اختصاصی صورت نمی‌گیرد. عملیات ذخیره سازی و ثبت هر لاگ میتواند از منابع یک سرور از قبیل حافظه و CPU و ... استفاده کند و اگر تعداد این وب سایت‌ها بالا باشد، باقی روش‌ها باعث فشار به سرور می‌شوند. برای همین ایجاد یک فایل خام از لاگها در این مواقع میتواند راهگشا باشد. برای همه یک فایل لاگ ایجاد شده و بدون قالب بندی ذخیره می‌کند. پسوند این نوع لاگها ibl است که مخفف Internet Binary Log می‌باشد. دلیل این تغییر پسوند این است که اطمینان کسب شود کاربر، با برنامه‌های متنی چون notepad یا امثال آن که به Text Utilities معروفند فایل را باز نمی‌کند. برای خواندن این فایل‌های میتوان از برنامه‌ی Log parser استفاده کرد. پروتکل‌های FTP,NNTP و SMTP در این حالت لاگشان ثبت نمی‌شود.