Обява

Свий
Няма добавени обяви.

Разни въпроси към WEB-аджиите...

Свий
X
 
  • Филтър
  • Час
  • Покажи
Изчисти всичко
нови мнения

  • #46
    От: Разни въпроси към WEB-аджиите...

    За езиците аз се отказах от вградените възможности на VS.NET и ползвам прости текстови файлове в INI формат (защото си предпочитам олдскул програмирането), които са елементарни за промяна от хора, които не им е работа да знаят какво е XML например. Имаме по един файл за всеки език, например lang-bg.txt, lang-en.txt, lang-de.txt.

    При логване лузера му се показват не само полета за име и парола, но и последно ползвания език, с който той е влизал в приложението. Това се пази в бозата, за това няма проблем. Възможните езици за превод може да се показват в някакъв комбо бокс, за да може да си избере друг, ако иска. Ако лузера се логва за пръв път и в базата няма инфо какъв език е ползвал, то му се предлага някакъв дефолтен език - например английски.

    За всяка форма, страница или просто някакви съобщения си дефинирам нова секция и разбираеми имена на променливи в INI файла. Давам текстовия файл на преводача и той ми го връща готов. След време се правят корекции след реално преглеждане как стоят съобщенията в даденото приложение. Самият клас, който се занимава с многоезичната поддръжка, има два режима: с кеширане на данните от тези файлове или винаги чете дадения превод от съответния файл, т.е. промяната в превода се вижда при рефреш на страницата или наново отваряне на формата (зареждам разните текстове за превод при лоадване на форма/страница). Така много лесно и бързо се оправят синтактични грешки в текстовете, изцяло замяна на преведени съобщения заради смисъла им и т.н. При изчистване на грешките в текстовете за ускоряване се пуска кеширането в паметта и така се подобрява леко скоростта (не че се вижда на новите машини, ама за собствено успокоение ).

    Ето и пример как изглеждат част от файл с преводи при мен:
    Код:
    ;----- SELECT PART FILE FORM -----------------------------------------
    [SelectPartFileForm]
    BTN_OK                = OK
    BTN_CANCEL            = Cancel
    FORM_TITLE            = Select document attached to the current part number
    LBL_SELECT_FILE_DESCR        = Please select file linked to current part number.
    LBL_CUR_PART            = No active part number set!
    CHK_REPLACE_ALL_INST        = Replace all instances
    CUR_PART_INFO            = Part Code: {0}, Rev: {1}, Description: {2}
    Последният превод (cur_part_info) съдържа параметри и се попълва вече от самото приложение, например със string format:
    Код:
    lblCurPart.Text = String.Format(GetLangString("SelectPartFileForm", "CUR_PART_INFO"), _
        PDMObj.CurrentPartName, PDMObj.CurrentPartRev, PDMObj.CurrentPartDescription)
    По подобен начин се ползва и при web-ско приложение:
    Код:
    lblErrorStartsOn.InnerText = CurrLang.GetLangString("Common Texts",
                                            "LABEL_DATE_EMPTY_ERROR");
    И предполагам веднага се вижда предимството на тези текстови файлове. Те могат да се ползват от различни приложения, правени с различни платформи и така няма да има нужда за различни версии на дадено приложение да се мислят различни методи за многоезична поддръжка.
    Последно редактирано от pecix; 26-07-12, 08:08.

    Коментар


    • #47
      Re: Разни въпроси към WEB-аджиите...

      Това е най използваната практика дали ще е ini или php или asp няма знчение - начина на дефиниране е подобен.

      PHP Код:
      $lang['snavreg'] = 'Register Now!';
      $lang['snavlogin'] = 'Log In';
      $lang['snavlogout'] = 'Logout';
      $lang['snavhelp'] = 'Help'
      Предимството е ясно - редактираш много бързо и добавяш супер лесно

      Коментар


      • #48
        От: Разни въпроси към WEB-аджиите...

        При .NET има и други възможности за многоезична поддръжка с ресурси, но не е съвместимо примерно с другите платформи, които може да се ползват (примерно добрите стари VB6 и Delphi), Java и какво ли още не, ползвано през годините. Така работата става двойна и тройна, а понякога и кошмарна заради проста промяна на една объркана буква. За това класическия INI формат и по един клас на дадените езици, който да се занимава с него

        Коментар


        • #49
          Re: Разни въпроси към WEB-аджиите...

          Аз може да съм малко старомоден но не бих използвал МВЦ за такова приложение, щях да си го напиша. Така изпускам проблемите на самото МВЦ. И знам какво съм правил а не какво ми е направено.

          Коментар


          • #50
            От: Re: Разни въпроси към WEB-аджиите...

            Първоначално публикуван от Daniel Преглед на мнение
            Аз може да съм малко старомоден но не бих използвал МВЦ за такова приложение, щях да си го напиша. Така изпускам проблемите на самото МВЦ. И знам какво съм правил а не какво ми е направено.
            Сециално при майкросовското MVC общо взето почти всичко може да се замени с къстъм такова, включително и обработката на заявки (то предполагам и при другите е така, но все пак да спомена). Става лесно. За другото все още нямам опит, иначе и аз трудно се навивам да ползвам готови неща, писани незнайно как и за какви цели, но за момента голям избор нямам. Някой ден може да ми изглежда и просто и смешно, но в момента се съсредоточавам да решавам проблем по проблем, вместо освен моята система да мисля как да напиша и още една.

            Другото - вградената аутентикация се оказа възможно най-гламавия вариант (поне от моя гледна точка) - юзернейма и паролата се пращат като текст, сървъра проверява има ли такъв и си прави куки с кодирано вътре ID на клиента. После при всяка заявка проверява за кукито и съдържанието му, и отбелазва в променлива на класа, в който е записана заявката с име "IsAutenticated" резултата от проверката. Разчита се изцало че който иска сигурност ще ползва SSL. Ние че ще ползваме SSL е ясно, но все пак такава проста концепция нещо не ми е по вкуса. Прав ли съм да не ми харесва?

            Горе споменаваш за кодиране - това предполагам на клиентската машина от скрипт, или имаш друго в предвид? Защото това, дето ми хвана окото по принцип е http://en.wikipedia.org/wiki/Digest_...authentication, но до колкото разбрах нямам контрол над това под каква форма броузера ще ми поиска юзер нейм и парола, ами си е изцяло вградена функция, според някой си стандарт. И не съвсем всички броузъри го поддържат. Правилно ли разсъждавам?

            Ако се кодира по твоя начин на клиентската машина от скрипт върху страницата, то самия скрипт ще е видим от сорса на страницата - (ако предположим че няма SSL), за който знае за какво иде реч. Да, по мрежата няма да текат текстови юзернейм и парола, но ако някой разгледа сорса на страницата ще знае как се кодират. Предимството е че от изчисленото трудно ще изкара самите юзернейм и парола (да не кажа невъзможно). Правилно ли схващам нещата?
            Интернет експлорър: Безплатно предоставян от Майкрософт тул за сваляне на браузер по избор.

            Коментар


            • #51
              От: Разни въпроси към WEB-аджиите...

              има такива подобни готови продукти - ТРЗ, Човешки ресурси, Документооборт - WEB базирани-ама явно Ви трябва индивидуалност.
              Материята засяга не само програмиране, но и нормативната им уредба към момента. Специално за РайФайзен банк приложенията им, както и за ИнтерАмерикан /ASPx/, за ИН Group по застрахователния им софтуер, WEB базиран който е в частта ТРЗ и управление, има намеса МикроКомлекс София ако се не лъжа.

              Подобни продукти в София - Управление на човешките ресурси и ТРЗ - Аладин, Владимир Зографски, Микрокомплекс София
              - Управление на документооборота и Човешки ресурси - Микси, Росен и Лидия Трашлиева, Микси София
              - Управление на ТРЗ и Човешки ресурси - Санта ТРЗ, Юлия Георгиева, Алгорита София, Смолян /Гравис БГ/.
              Продуктите ги има в различни версии и локални и УЕБ базирани, ориентировъчно с това за което става въпрос по горе. Мога да ти отговоря само за частта с бази данни, която ползвам на SQL Server 2005, но ще изникнат и други въпроси, на които не мога да отговоря.
              Ако някой познава нещата накуп - то това са И тези екипи. Има им координатите/телефони/имейли в информацията за фирмите, ... само да проверя нещо ... - Владимир Зографски, Александър Александров и екипа им мисля, че са членове тук - Дано зърнат темата.
              Последно редактирано от rpkn; 26-07-12, 10:11.
              [I][SIZE=1]...системен администратор-винаги има начин...:)[/SIZE][/I]

              Коментар


              • #52
                От: Разни въпроси към WEB-аджиите...

                Спарки, даден уеб сайт може да бъде защитен на ниво уеб сървър, т.е. да се изисква аутентикация при логин на обикновена страница, която си е просто статична. Там стандарта не знам как е в момента, но преди няколко години беше голямо мазало със съвместимостта с броузерите. С майкрософтското IIS и броузери под линукс просто нямаше логване.

                Вероятно е паролите да са в plain text при такава аутентикация е много голяма, но пак зависи от настройките на сървъра и възможностите на броузера.

                Ползването на логин страница, която сам си направил, ти дава възможност да си криптираш с някакъв javascript паролата и да я изпратиш към сървъра. Така поне малко ще затрудниш "слушащите" Както и Даниел ти е писал, ползването на salt е много важно, защото вече има достатъчно мощни машини, с които се откриват достатъчно бързо конфликтни стойности от хеша. А и на този някой не му пречи да си промени леко страницата и просто да праща директно прехванатия хеш вместо да се мъчи да търси каква е била паролата. То за това вече се минава и към SSL-а де, за да не може подслушващия да разкодира каквото и да било в комуникацията броузер-уеб сървър.

                Ако ползваш hash на паролата + salt стойност, може да добавиш генериране на нов salt за всяка нова логин сесия, та да не може да се ползват прехванатите хешове.

                Вече за криптирането на самите пароли в базата си решаваш сам, но следните материали дават интересни насоки защо старите методи вече не са толкова сигурни:

                Redux: Are you sure SHA-1+salt is enough for passwords?
                http://www.f-secure.com/weblog/archives/00002379.html

                Still using the default setting on your password safe? Don't.
                http://www.f-secure.com/weblog/archives/00002382.html

                No, Heavy Salting of Passwords is Not Enough, Use CUDA Accelerated PBKDF2
                http://www.f-secure.com/weblog/archives/00002384.html

                Коментар


                • #53
                  От: Разни въпроси към WEB-аджиите...

                  Първоначално публикуван от rpkn Преглед на мнение
                  има такива готови продукти - ТРЗ, Човешки ресурси, Документооборт - WEB базирани.
                  Материята засяга не само програмиране, но и нормативната им уредба към момента.
                  Подобни продукти в София - Управление на човешките ресурси и ТРЗ - Аладин, Владимир Зографски, Микрокомплекс София
                  - Управление на документооборота и Човешки ресурси - Микси, Росен и Лидия Трашлиева, Микси София
                  - Управление на ТРЗ и Човешки ресурси - Санта ТРЗ, Юлия Георгиева, Алгорита София, Смолян /Гравис БГ/.
                  Продуктите ги има в различни версии и локални и УЕБ базирани, ориентировъчно с това за което става въпрос по горе. Мога да ти отговоря само за частта с бази данни, но ще изникнат и други въпроси, на които не мога да отговоря.
                  Ако някой познава нещата накуп - то това са И тези екипи. Има им кординатите/телефоните/имейли в информацията за фирмите, ... само да проверя нещо-Владимир Зографски, Александър и екипа им мисля, че са членове тук - Дано зърнат темата.
                  Добре ми е известно какво има и няма, кой ни е конкуренция и кой не. Фирмата ни е на над 20 години и с един от най-големите пазарни дялове в бранша (тръгнала е от единствената някога фирма в тоя бранш въобще, и не е спирала да работи от тогава). Лично аз с това си изкарвам хляба 12 години вече, и веднъж вече съм пренаписал всичко из основи.

                  Дето се казва - ти нормативната уредба остави на нас. Ноухау-то - също. Налично е.

                  Ама, темата не е за това (справка - заглавието). Имам конкретни въпроси относно каквото е ново за мен, а именно WEB частта. Другото е моя грижа и там знам какво трябва и какво не.
                  Интернет експлорър: Безплатно предоставян от Майкрософт тул за сваляне на браузер по избор.

                  Коментар


                  • #54
                    От: Разни въпроси към WEB-аджиите...

                    Първоначално публикуван от pecix Преглед на мнение
                    Спарки, даден уеб сайт може да бъде защитен на ниво уеб сървър, т.е. да се изисква аутентикация при логин на обикновена страница, която си е просто статична. Там стандарта не знам как е в момента, но преди няколко години беше голямо мазало със съвместимостта с броузерите. С майкрософтското IIS и броузери под линукс просто нямаше логване.

                    Вероятно е паролите да са в plain text при такава аутентикация е много голяма, но пак зависи от настройките на сървъра и възможностите на броузера.

                    Ползването на логин страница, която сам си направил, ти дава възможност да си криптираш с някакъв javascript паролата и да я изпратиш към сървъра. Така поне малко ще затрудниш "слушащите" Както и Даниел ти е писал, ползването на salt е много важно, защото вече има достатъчно мощни машини, с които се откриват достатъчно бързо конфликтни стойности от хеша. А и на този някой не му пречи да си промени леко страницата и просто да праща директно прехванатия хеш вместо да се мъчи да търси каква е била паролата. То за това вече се минава и към SSL-а де, за да не може подслушващия да разкодира каквото и да било в комуникацията броузер-уеб сървър.

                    Ако ползваш hash на паролата + salt стойност, може да добавиш генериране на нов salt за всяка нова логин сесия, та да не може да се ползват прехванатите хешове.

                    Вече за криптирането на самите пароли в базата си решаваш сам, но следните материали дават интересни насоки защо старите методи вече не са толкова сигурни:

                    Redux: Are you sure SHA-1+salt is enough for passwords?
                    http://www.f-secure.com/weblog/archives/00002379.html

                    Still using the default setting on your password safe? Don't.
                    http://www.f-secure.com/weblog/archives/00002382.html

                    No, Heavy Salting of Passwords is Not Enough, Use CUDA Accelerated PBKDF2
                    http://www.f-secure.com/weblog/archives/00002384.html
                    Интересува ме механизма, по който това действа - разбирай, Login страницата е писана от мен. Върху нея има полета за юзернейм и парола. При простия случай като натиснеш бутона се праща POST заявка с попълнените вече полета. Това значи да се вижда с просто око само като прихванеш заявката, ако тя не е кодирана. Пак казвам - SSL-а ще е задължителен, така или иначе - тогава има ли смисъл да мисля от изчекнати по-изчекнати кодировки при LogIn-а, или да оставя SSL-а да свърши това, дето върши. Струва ми се че едно второ ниво на защита би било по-добре от нищо.

                    Относно другото, въпросите са два:
                    1. Къде става кодирането - върху клиентската машина от javascript (или каквото и да е друго) във въпросната login страница, или по някакъв друг механизъм?

                    2. Ако кодирането е от скрипт върху страницата, вървящ върху клиентската машина - то тоя скрипт е видим, така или иначе. Прав ли съм? Ако е видим може да се види и как кодира информацията. Прав ли съм? (ако приемем че някой е поседнал на клиентската машина "да разгледа", и ей-така между другото си запише сорса на страницата, или поне частта, която се вижда, защото върви на клиентската машина)

                    Другото (със "солта") го разбрах как работи. Правил съм подобни неща, но не WEB базирани.
                    Последно редактирано от sparkybg; 26-07-12, 10:33.
                    Интернет експлорър: Безплатно предоставян от Майкрософт тул за сваляне на браузер по избор.

                    Коментар


                    • #55
                      Re: Разни въпроси към WEB-аджиите...

                      Прав ли съм да не ми харесва?
                      - няма да е проблем ако ползваш SSL там си е криптирано и трудно се подслушва.
                      Примера който съм дал е за криптиране на паролите от сърверната страна в базата данни. Иначе паролите си тичкат като текст от юзъра до сървера и евентуално може да се подслушват.
                      Примера е даден за ПХП но при всички езици е еквивалентен - това няма как да се види като метод в сорса. Наистина може да се добави и едно JS криптиране на клиентската машина, но е излишно при SSL конекция.

                      Има много хакове за хеш, включително използвайки ГПУ то на видеокартата - там стават чудеса
                      НО все пак трябва да го вземеш този хеш отнякъде

                      Демек старница с пост заявка отлита до сървера в плейн текст. Ако не се кодира допълнително на клиентската машина с JS.

                      Коментар


                      • #56
                        От: Re: Разни въпроси към WEB-аджиите...

                        Първоначално публикуван от Daniel Преглед на мнение
                        - няма да е проблем ако ползваш SSL там си е криптирано и трудно се подслушва.
                        Примера който съм дал е за криптиране на паролите от сърверната страна в базата данни. Иначе паролите си тичкат като текст от юзъра до сървера и евентуално може да се подслушват.
                        Примера е даден за ПХП но при всички езици е еквивалентен - това няма как да се види като метод в сорса. Наистина може да се добави и едно JS криптиране на клиентската машина, но е излишно при SSL конекция.

                        Има много хакове за хеш, включително използвайки ГПУ то на видеокартата - там стават чудеса
                        НО все пак трябва да го вземеш този хеш отнякъде

                        Демек старница с пост заявка отлита до сървера в плейн текст. Ако не се кодира допълнително на клиентската машина с JS.
                        А, ей-това ми трябваше! Благодаря за което. Значи съм си представял малко или много правилно нещата.

                        Акаунтите върху сървъра - те и в момента се съхраняват в мой си бинарен файл, с няколко кодировки една върху друга + тук-там компресия измежду тях. Променяш един бит във файла, и той вече изглежда по тотално различен начин от край до край. За 12 години няма пробив, а седи свободно по клиентските машини, та все някой се е пробвал, предполагаемо и по-сериозно (щото не е като да нямаме конкуренция). При това начина на кодировка се сменя веднъж или 2 пъти годишно при по-големи платени ъпдейти, та и някой да е пробил нещо, ще му се наложи пак да се бори като прасе с тикви.

                        Благодаря, пак. Това беше точния отговор на въпроса ми.
                        Интернет експлорър: Безплатно предоставян от Майкрософт тул за сваляне на браузер по избор.

                        Коментар


                        • #57
                          От: Разни въпроси към WEB-аджиите...

                          sparkybg, няма много смисъл да откриваш топлата вода. Почти за всичко в MVC.NET си има хубави и удобни примери - намери си един пример с MembershipProvider, къстъмизирай си го и си готов. За логин ползвай FormsAuthenticationCookie:

                          FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(
                          1,
                          user.UserName,
                          DateTime.Now,
                          DateTime.Now.AddMinutes(10),
                          false,
                          null);

                          string encryptedTicket = FormsAuthentication.Encrypt(ticket);
                          HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
                          this.Response.Cookies.Add(cookie);
                          За паролата - щом си имаш собствен файл - най-лесно и удобно е да си направиш един клас който наследява IPrincipal(Май това беше), и го инициализираш винаги като Request.User, и оттам си го ползваш измежду страниците.

                          За локализацията си има всичко вградено - http://www.hanselman.com/blog/Global...ueryPart1.aspx. От stackoverflow.com можеш да си намериш почти всякакъв код...
                          Последно редактирано от Tihomir(imageo); 26-07-12, 12:27.
                          Вярата в конспирации е опростяване, което ни помага да обясняваме всичко.

                          Коментар


                          • #58
                            От: Разни въпроси към WEB-аджиите...

                            В хтмл-а:
                            Код:
                            <html>
                            <head>
                            ...
                            <script src="scripts/md5.js" type="text/javascript"></script>
                                    <script src="scripts/sha1.js" type="text/javascript"></script>
                            ...
                            function HashPassword() 
                            {
                                 document.getElementById("frmLogin").MD5Password.value = hex_md5(document.getElementById("frmLogin").TxtPassword.value);
                                 document.getElementById("frmLogin").SHA1Password.value = hex_sha1(document.getElementById("frmLogin").TxtPassword.value);
                                 document.getElementById("frmLogin").screenWidth.value = screen.width;
                            }            
                            </script>
                            ...
                            <body>
                            ...
                            <form id="frmLogin" action="Login.aspx" method="post" runat="server">
                            ...
                            <input type="password" name="TxtPassword" size="20" maxlength="50" />
                            <input type="hidden" name="MD5Password" />
                            ...
                            </form>
                            В кода отзад:
                            Код:
                            public void DoLogin()
                            {
                            ...
                                string hashedPass = Request.Params["MD5Password"].ToUpper();
                                      
                            ...
                            }
                            Ако добавиш някакъв salt при всеки логин, така ще можеш да си вземеш разлишен хеш всеки път, който ти да си сравниш с някакъв от базата, ползвайки новогенерирания salt към паролата, която си имаш. Така поне ще си сигурен, че паролата не е плейн текст, а не да разчиташ само и единствено на SSL-а.

                            Коментар


                            • #59
                              От: Разни въпроси към WEB-аджиите...

                              Първоначално публикуван от Tihomir(imageo) Преглед на мнение
                              sparkybg, няма много смисъл да откриваш топлата вода. Почти за всичко в MVC.NET си има хубави и удобни примери - намери си един пример с MembershipProvider, къстъмизирай си го и си готов. За логин ползвай FormsAuthenticationCookie:



                              За паролата - щом си имаш собствен файл - най-лесно и удобно е да си направиш един клас който наследява IPrincipal(Май това беше), и го инициализираш винаги като Request.User, и оттам си го ползваш измежду страниците.

                              За локализацията си има всичко вградено - http://www.hanselman.com/blog/Global...ueryPart1.aspx. От stackoverflow.com можеш да си намериш почти всякакъв код...
                              Точно това направих снощи по никое време(с аутентикацията). Работи. Само мъдрех дали е достатчно.

                              Първоначално публикуван от pecix Преглед на мнение
                              В хтмл-а:
                              Код:
                              <html>
                              <head>
                              ...
                              <script src="scripts/md5.js" type="text/javascript"></script>
                                      <script src="scripts/sha1.js" type="text/javascript"></script>
                              ...
                              function HashPassword() 
                              {
                                   document.getElementById("frmLogin").MD5Password.value = hex_md5(document.getElementById("frmLogin").TxtPassword.value);
                                   document.getElementById("frmLogin").SHA1Password.value = hex_sha1(document.getElementById("frmLogin").TxtPassword.value);
                                   document.getElementById("frmLogin").screenWidth.value = screen.width;
                              }            
                              </script>
                              ...
                              <body>
                              ...
                              <form id="frmLogin" action="Login.aspx" method="post" runat="server">
                              ...
                              <input type="password" name="TxtPassword" size="20" maxlength="50" />
                              <input type="hidden" name="MD5Password" />
                              ...
                              </form>
                              В кода отзад:
                              Код:
                              public void DoLogin()
                              {
                              ...
                                  string hashedPass = Request.Params["MD5Password"].ToUpper();
                                        
                              ...
                              }
                              Ако добавиш някакъв salt при всеки логин, така ще можеш да си вземеш разлишен хеш всеки път, който ти да си сравниш с някакъв от базата, ползвайки новогенерирания salt към паролата, която си имаш. Така поне ще си сигурен, че паролата не е плейн текст, а не да разчиташ само и единствено на SSL-а.
                              Тенкю. Дано да се видим скоро да почерпя!

                              ПП: Само едно въпросче - salt-а може да го задавам от сървъра при инициализацията на страницата пак в скрито поле, предполагам? Мога да генерирам различен салт при всеки логин - това е ясно. Даже е редно.
                              Интернет експлорър: Безплатно предоставян от Майкрософт тул за сваляне на браузер по избор.

                              Коментар


                              • #60
                                От: Разни въпроси към WEB-аджиите...

                                Да, salt-а си го генерираш при заявка за страницата и си го слагаш някъде вътре като скрито поле. Даже може да си генерираш собствени жаваскриптове, с които допълнително да усложняваш нещата, но там пък кеша на броузера може да изиграе кофти номер.

                                Та ще имаш:
                                - генериране на salt при заявка към страницата
                                - с джава скрипт си генерираш hash(password+salt) и си го слагаш в някакво друго поле
                                - при постбак си взимаш хеша от на паролата от страницата
                                - генерираш си на сървъра hash(парола от базата + salt) и там вече си сравняваш какво къде и как

                                Ние още не сме го правили със salt при паролата от броузера, но е планирано при следващ голям рилийз да се пусне тази промяна, защото сме вече почти в 2013-та година и е опасно. То и преди 8-9 години си беше опасно, че тогава в стара версия на едно старо уеб приложение си пазеше паролите чисти в базата, а за хеш май никой не беше чувал тогава. Но като го подхванах и всичко се промени

                                Коментар

                                Активност за темата

                                Свий

                                В момента има 1 потребители онлайн. 0 потребители и 1 гости.

                                Най-много потребители онлайн 8,787 в 16:37 на 21-06-23.

                                Зареждам...
                                X