תחומים - פורום חרדי מקצועי

@חסויה ישנם שלושה הודעות בתמונות:

1. מסך כניסה של גוגל דרייב
2. התוכנה של הנטסטיק
3. שגיאה של תוכנת בבילון

-1 אם אתם לא יודעים או לא צריכיכם את גוגל דרייב, הכי טוב להסיר את התוכנה הזו ב"אפליקציות ותוכנות", אין בזה כל סיכון ובכל מקרה שתתחרטו תוכלו להורידה שוב ולהתקינה. אם אתם מכירים/צריכים אתם אמורים פעם אחת להיכנס עם חשבון גוגל ויותר ההודעה לא תופיע.
-3 זה הודעה (קצת מפחידה) של תוכנת בבילון, כשלב ראשון להסיר אותה מאתחול כמו ששרגא הציע: קליק ימני על שורת המשימות > מנהל המשימות > ("יותר פרטים" אם מופיע) > כרטסת אתחול > קליק ימני על פריט שמכיל את המילה babylon והפוך ללא זמין.
כהמלצה פחות דחופה אני מציע גם להסיר את התוכנה לגמרי.
-2 התוכנה של הנטסטיק ייתכן שאתם צריכים שהיא תופעל, כי יש נטסטיקים שפעולתם תלויה בתוכנה. כיום מערכת ויינדוס יודעת להתחבר גם דרך נטסטיק ישן ללא תוכנה אבל לא תמיד ואיני יודע להדריך כיצד. תוכלו פשוט להפוך אותה ללא זמינה במנהל המשימות כנ"ל, להפעיל מחדש את המחשב. אם הנטסטיק/האינטרנט יעבוד, התוכנה לא נדרשת.

אני לא יודע מה לעשות, אבל תחשוב - לא נפלו עליך "סתם".
פה למשל בעצם פרסום הפוסט עברת על כלל קטן - פתחת בקטגוריה לא מתאימה. עם תיזהר יותר בכללים של פורומים (הפרטניים של כל פורום והכלליים שכולם יודעים) אני בטוח שלא תיחסם.
אם אתה באמת חושב שסתם סתם עשו הגרלה ונפלו על הניק שלך, אז באמת אין מה לעשות (כלומר איתך - כי ברור שאתה טועה).
ואם זה לא סתם -
ראשית, תיזהר מאוד מכאן ולהבא
שנית פתח ניק חדש דף חדש.

@אביי אמר בהמלצה על טלפון נייד חזק ופשוט:

אגב, זה אמור להיות כאן או בצרכנות?

שניהם מתאימים,
באופן כללי אם מנסים לחשוב כבר יוצאים ידי חובה, הטענה היא על פרסום חסר מחשבה.

זה לא "ניסיון פריצה" מיוחד, זה שגרת חיים של שרת לקבל מאות נסיונות חדירה ביום.
הבעיה היא לא הנסיונות אלא החוסר מודעות של מנהל השרת, במקרה הזה יצאת הרגע מהסכנה, אם תשכיל להשתמש בשרת בידיעה שזה המצב.
אחרי שאתה מודע לזה אתה לא אמור לחשוש מזה אם אתה נוהג בהתאם: כל השירותים סגורים ומה שפתוח מוגדר היטב.
זה ממש טוב שראית את זה, קיבלת שיעור יקר בחינם, אל תאבד אותו...
בשרת רגיל יש חומת אש סגורה, במקרה שלך היא פתוחה. אתה צריך לסגור הכל, ומה שצריך להיות פתוח לחשוב טוב האם אין דרך בעולם להגיע משמה למידע/פקודה לא רצויה.
בהצלחה.

לאט לאט, הכל יסתדר.
כנראה תישאר חפיפה מסויימת אבל זה לא נורא.
כמובן שהכל בזכות @בערל... וגם שיתו"פ של @ג-מייקה!

https://www.blog.google/products/gmail/master-your-email/

@shraga ההשערות ש@צדיק-תמים אמר הם עובדות:
א. הרשמים שמביאים מחיר זול מפסידים עליך ועוקצים אותך במגוון דרכים אחרות (לפעמים על ידי מחיר שנה שניה, אבל עוד הרבה דברים, למשל שאתה בכלל נמצא אצלם). קל לוודא את זה עם סיומות כמו .com שהמחיר האמיתי שלו שקוף לציבור, מעל 9 דולר. בהרבה חברות אתה יכול לקבל את זה בפחות בשנה ראשונה.
ב. המחיר האמיתי של הדומיין .forum הוא כמעט כלום. החברה שמחזיקה בו (Fegistry) לוקחת סכום בלתי ידוע מהרשם - זה חוזה פרטי בין החברה שבעלים על הסיומת לבין הרשמים, וסביר שכל רשם מקבל מחיר אחר לפי כוחו בחוזה. עם זאת סביר שcloudflair קיבלה מחיר טוב, כך שפה זה לא הנקודה לדעתי.

הנקודה הראשונה חשובה מאוד.
החברות שעושות כסף מרישום דומיינים הם חברות "זולות" במובן השלילי של המילה. קהל היעד הם ברמה נמוכה: מתחילים/טירונים, חסרי ניסיון, או רמאים.. כל חברה שמציעה מחיר זול לשנה שניה, בעצם אומרת מפורש שהיא פונה לכאלו שמנסים את דרכם או מהמרים, או מקימים דברים זמניים. אם הכסף שלך מגיע מהחתך הזה (וזה בדרך בגלל שאתה באמת לא מספיק מקצועי/יוקרתי), אתה עושה הרבה קומבינות כדי להגדיל את הכסף, כי אתה לא מתעסק עם עשירים.
הקומבינות הידועות לי הם סל המוצרים הגרוע עם מגוון הונאות ומלכודות, שנה שניה וכל מיני כאלו, אבל מה שלא ידוע עשוי להיות גרוע בהרבה. סביר מאוד בעיני שהם מוכרים מידע, למשל את פרטי מחזיק הדומיין או לפחות סטטיסטיקות עליו.
בקיצור, מי שלא מתעסק עם אנשים חשובים, חשוד להתנהג בצורה בזויה.

@יעקב-מ-פינס לא הייתה לי שום טענה עליך!
רק ביקשתי לא לעשות מדריך לכאלה שצריכים מדריך מלא.
למה?
מנסיוני זה מביא המון נרשמים לפורום,
שמגיבים במקרה הרע או פותחים נושא במקרה הטוב נטו בשביל השלב בו הם לא הבינו ולא בגלל קוצר דעתם (אלא בגלל קוצר מאמצם לקרוא יותר מפעם אחת הוראות),
שואלים במילים ספורות עם שגיאות כתיב שאלה בלתי ממוקדת שגוררת הרבה עזרה מכיוונים שונים בבלגן מושלם, ואז נעלמים להם (ואם לא יותר גרוע).
השאיפה שלי שיהיו פה בפורום אנשים מיושבים שיש להם יישוב הדעת לשאול/לענות/לקרוא. כנראה זה עניין של גיל/עיסוק.

@אלף-שין הפתרון שלך יפה, אבל הם צודקים שהענישו אותך, כי אין ספק שיש דרכים להשיג אייפי של מישהו, אבל השאלה שם הייתה איך למצוא את זה לפי מייל שהוא שלח או שתשלח אליו. הרעיון שלך מתעלם מהקושי המרכזי, איך לגרום לשני לעשות מה שמתחשק לך שהוא יעשה.
זה כמו הסיפור על הרשלה שמכר חומר להשמדת ג'וקים. כשהתלוננו הלקוחות שזה לא עובד אז הוא שאל אותם האם הם פעלו לפי ההוראות, הלקוחות שאלו מה ההוראות ואז הוא הסביר להם שיש לתפוס את הג'וק ולדגדג אותו בבטנו, ואז כשהפה שלו פתוח להכניס לו את החומר לפה ולסיום לדפוק עליו חזק עם נעל בית...
הרעיון שלך הוא שליחת פיתיון: "בא תיכנס למייל הזה עם הסיסמה הזו, אתה חייב לראות מה יש שם" באותה מידה אתה יכול לומר לו שכדאי לו להקריא מה כתוב בגוגל בחיפוש What's my IP. זה מלכודת שתעבוד על הרבה אנשים, אבל היא לא יעילה ברמה גבוהה. פה דיברו על רעיון לתת לו לינק למשהו מעניין/מסקרן שהלינק הזה עובר דרך שירות שאח"כ ידווח לך על המידע הנדרש, זה יותר פשוט מפתיחת מייל ייעודי לצורך העניין מצד אחד אבל אולי מצריך יותר ידע טכני שאכן ברעיון שלך חסכת, שאפו.
.

@MusiCode אמר בהנה זה - אקסס ווב!:

אשמח לעדכונים והרחבות בנושא, כמו על ידיעה מתי זה יהיה זמין גם לנו, ובעברית.

מי שמכיר את היסטוריית המוצרים של גוגל,
יודע שיש די הרבה סיכויים שהמוצר יפסיק להתקיים פתאום.
אבל תודה רבה על הידיעה, זה פתרון נפלא.

קודם כל הרעיון הוא שיש לך כתובת ציבורית למשל 200.200.200.200, וכיום הכתובת הזו מגיעה לראוטר שלך שלא עושה עם זה כלום כי לא אמרו לו מה לעשות, למשל מגיע אליו RDP אז הוא פשוט לא מתייחס. צריך לומר לו "קח את מה שמגיע אליך ותעביר למחשב בבית, ההוא שהאייפי שלו הוא 10.0.0.15".

לא אומרים את זה באופן גורף (כי אז לא תהיה גישה מבחוץ למחשבים אחרים בבית במידה וירצו) אלא אומרים בד"כ מפורט X עד Y תעביר למחשב Z, עם אותו הפורט שהתקבל או פורט אחר.

כעת איך עושים:
אתה צריך בראוטר להיכנס למקטע ששמו Port forwarding (הפנייית/ניתוב פורטים).
שמה אפשר להוסיף כלל חדש (יש גם רשימת כללים מוכנים שאין בהם את הRDP).
בעת הוספת כלל חדש לניתוב יש כמה שדות שמשתנים לפי הראוטר,
אני מצרף תמונה מהראוטר שלי כעת:

במקרה שלי יש דבר ראשון שדה של Source IP שמגביל את כל העסק רק לתקשורת שבא מאייפי/טווח מסויים, זה טוב לאבטחה (בהערה אומר שחובה ממש לקבוע סיסמה קשה למשתמש, פריצות לRDP מגיעות עם כופר וזה נזק עצום) תשקול אם למלא את זה. 0.0.0.0 משמעותו הכל.
השדה השני Destionation IP הוא מאוד חשוב, זה הכתובת הפנימית של המחשב הרצוי בבית.
מתחת יש כמין טבלה,
בפרוטוקול יש לבחור בTCP+IP, בstart יש לתקוע מספר בין 4 ספרות ל32767, ובend לשים את אותו אחד (העניין לבחור מספר שונה מ3389 שזה הפורט ה"סופי" אליו צריך להגיע הוא בשביל להוות עוד גדר אבטחה קטנה בפני סריקה אקראית של בוטים).
בStrat האחרון יש לשים את הפורט 3389 שזה הפורט במחשב שלך שהתקשורת לבסוף תגיע אליו, וזה הפורט ברירת המחדל של RDP.

אם יש בעיות תשתף.

@margalit זה בציניות או ברצינות?
כי בכותרת שמתם סימני שאלה וקריאה לסירוגין.

דבר ראשון, הוא עוד לא הספיק, הפורום בקושי נולד לפני שבועיים.
דבר שני, זה לא כדאי. מערכת שגודלת באחת היא לא בריאה, וחסרת קו ואופי אמיתי וחסון, שרק התבגרות איטית ונשלטת יוצרים אותם.

@nach אמר בהאם זה מעניין כאן מישהו מדריך על בניית אתרים סטטיים?:

תרצה שאפציץ אתכם בשאלות?

כן בכל ליבי!!

@MusiCode כלום כלום כלום.
העלות השמה וקריאה לפונקציות וכדומה היא זניחה במידה קיצונית, מדובר על פער כה קטן שאין הצדקה בעולם לקחת אותו בחשבון כשיש איזושהיא תועלת נגדית ועל אחת כמה וכמה כשזה משפיע לרעה על קריאות הקוד.

לפני שאתחיל אקדים שייתכן שאפשר לראות בתשובה שלי בריחה מהשאלה. תשובה טובה אמורה לרדת לשורש הבעיה שהצוגה, ולתת פתרונות אופרטיביים לגביה. אבקש בכל אופן להתייחס לדברי כי זו לא דעתי אלא דעת רוב המבינים היום.

התשובה הקצרה ביותר לכל השאלות זה nodejs, ועכ"פ, לא PHP.
אני יסביר: הכח של השרת מספיק לארבע קמפיינים ויותר. זה לא מה שדגדג לו.
הבעיה היא התקורה של הבקשות בPHP, ובכלל כל האופן בו PHP עובד.
א. כל בקשה, זה עולם חדש. stateless במיטבו.
ב. כל בקשה זה טריד עצמאי שנגמר עם סיום הבקשה.

שני החלקים עושים תקורה גבוהה:
א. אתה חייב לטעון ללא הרף מידע ולו הפעוט ביותר ו/או לחשבון הכל מאפס במידה וזה נדרש.
ב. הרמת תהליך ומספר התהליכים בו זמנית זה בהחלט משאבים יקרים מאוד יחסית ללולאה שבודקת סידרת פיבונאצ'י.

לעומת זאת בnodejs למשל,
א. כל הבקשות רצות על אותו קונטקסט משותף, אתה יכול לשמור את מספר המבקרים במשתנה, ללא שום SQL.
ב. הכל טריד אחד, כל בקשה מתבקשת לחכות עד שהשרת משועמם (!) ואז הוא עונה לה.
זה גורם לכך ששרת בעל כח X יכול לשרת פי מאה בנוד מאשר בPHP. כמובן שזה תלוי עד כמה ארכיטקט התכונה התחשב באופי השפה, אבל בתצורה שלך אז ייתכן שמדובר בפי אלף.

עבורך, יש לנוד חיסרון אחד בלבד. הוא טיפה רגיש יותר וצריך יחס יותר מעמיק מאשר PHP שמסתכם בתיקיית קבצים. בגלל שזה תוכנה בעל מופע אחד, אז אם יש שגיאה לא הבקשה קורסת אלא פשוט התוכנה=השרת. אז זה לא בעיה, כי לומדים איך להגדיר שיעלה לבד וגם איך לא לעשות שגיאות, אבל זה בהחלט ריזיקלי בשבילך לקפוץ לזה.

יש גם את ASP CORE שמשלב בין שתי הדרכים: כל בקשה היא טריד נפרד אבל באותו פרוסס וממילא מצד אחד יש תקורה קטנה של יצירת התהליכים אבל מאידך יש את מעלת הmulti-treading.
אני, אופיינית, תומך בדרך זו

אני יודע שאתה חושב: "מה הוא שוב פעם חושב שיש לי זמן ללמוד שפות חדשות".
א. לא. אל תגיד את זה, תלמד שבועיים בלי לנשום ואח"כ תטען מקח טעות, בא נראה אותך.
ב. זה בכלל לא מסובך, וזה חובת המציאות אם אתה רוצה לא להשתמש כל החיים עם הפתרון הראשון שלמדת.

ההמלצה שלי היא ASP.NET MVC. לא בגלל הרעיון עצמו, אלא
א. פשוט כל ההיבטים המודרניים של תעשיית התוכנה הוטמעו שם די טוב.
ב. הASP.NET הרגיל עובד עם WebForms ובן לוייתו ViewState שלדעתי זה טכנולוגיה נוראה. עדיף PHP או כל דבר אחר מזה.

נ.ב. הייתי ממליץ על ASP.NET MVC CORE, שזה גלגול מודרני יותר (בהרבה דברים), וכבונוס הוא חוצה פלטפורמות ורץ על כל מערכת.

שאלת מה ההבדלים. אז WebForms זה פשוט זבל. אין טען להתייחס לעבודה הכבירה שנעשתה שם שפשוט לא לקחה בחשבון את אופי הארכיטקטורה והתכנות בווב.

לעומת זאת, איך עובד MVC בASP.NET:
קודם כל MVC זה תבנית עיצוב של תוכנה שנמצאת במגוון שפות וטכנולוגיות. הרעיון שלה הוא שהמשתמש עובד מול תצוגה (V), התצוגה נוצרת ע"י הבקר (C), ואותו הבקר הוא גם זה שמגיב על אירועי/בקשות המשתמש דרך התצוגה (ביישום אינטרנט המונח הנכון זה בקשות). הבקר עצמו ממונה רק על התקשורת, כשהמידע הגולמי מועבר/מתקבל על ידו מ/אל המודל (M).
זה יפה לתיאוריה, למעשה יש חופש בתוך הכללים האלה.
בASP.NET הMVC נבנה עם הרבה השראה מRuby on Rails, שכוללת עקרונות שונים כמו CoC - Convention Over Configuration, שזה אומר בעברית "מוסכמות על פני הגדרות" - ההשלכה המעשית: כל פרט שניתן להניח מה תהיה ההגדרה שלו, זו התנהגותו ללא כתיבת הגדרה זו בפירוש. הכלל הזה ממש מכסה את כל מערכת הMVC בASP.NET.
עקרונות הליבה של יישום ASP.NET MVC:

1. ניתוב - Routing.
   ביישום אינטרנט מסורתי שורש הURL בעצם מפנה לשורש תייקת האתר, והנתיב מכאן ואילך הוא ביחס לשמה תיקיה בתוך תקיה וכו' עד לקובץ המתאים, למשל: http://example.com/directory-a/directory-b/file.php
   ביישום MVC הניתוב הוא מופשט ובלי קשר למבנה תיקיית האתר. בעצם ישנו "מטפל" אחד בכל הנתיבים, שלפי הנתיב מנתב למתודה של קונטרולר. בברירת מחדל (מוסכמה) האיבר הראשון אחרי שורש האתר מצביע על שם הקונטרולר, והשני על מתודה שבו, אלא שאחריהם יכולים להיות מנותבים לפרמטרים למתודה.
2. בקרים - Controllers
   יכול להיות כמה בקרים שרוצים, ברך כלל הם תחת תיקיה בשם Controllers. בכל Controller יש כמה מתודות, כל אחת בדרך כלל אחראית לייצר תצוגה.
   (יש גמישות מלאה איזה מתודות לשים באיזה בקר, בעצם זה נטו עניין של טעם אישי וסדר כמו תיקות וקבצים).
3. תצוגות - Views
   הרעיון של תצוגה בMVC זה פיסת פרוצדורה שלא עושה שום דבר שלא נוגע לתצוגה, והיא מתקשרת אך ורק עם הController.
   בASP.NET נעשה שימוש במנוע תצוגה נח וקל מאוד בשם RAZOR הוא הטוב ביותר שקיים לדעתי.
   התצוגות בדרך כלל מקובצות בתיקיות כשכל קבוצת תצוגות ששייכת לבקר מסויים נמצאות תחת תיקיה כשם הבקר, שהיא תחת תיקיה ראשית בשם Views.
4. מודלים
   זה "סתם קוד", שעל פי הכללים עדיך לעשות בו את הלוגיקה והעבודה עם המסד נתונים וכו' מאשר בבקר. כמובן שאין על זה קנסות מהמשטרה ואפשר להתגמש אבל זה הדרך לפי הספר.

בקשר לשפה, יש לך את VB בשניהם, כלומר VB.NET, יש חלקים מתקדמים בשפה כמו Attribute שהופכים בMVC להיות בשימוש תכוף מאשר בטכנולוגיות אחרות, אבל אלו לא דברים שמחייבים הבנה מעמיקה.

הספרים יש רק אחד, השני, והוא תרגום חלש אבל רע במיעוטו.

אני מעודד לקפוץ למים גם תוכל לקבל פה עזרה ובפרט בפורום האקסקלוסיבי.

שאלה דומה בסטאק:
https://stackoverflow.com/questions/27972271/sequelize-dont-return-password
אני חושב שזו דוגמה טובה לבלגן ה"איך" ששורר בnodejs.
בעוד בC# יש עומס מרגיז של שיטות וכללי עצוב, בנוד חסר מאוד כאלו.
אגב הרבה לא שמים לב למשהו שיותר מסוכן - הכיוון ההפוך של קבלה מלקוח,
כשמקבלים מהלקוח אובייקט יש סכנה יותר הפוכה שנקראת Mass Assignment או Overposting שזה מתי שהקוד בצד שרת מקבל אובייקט ולמשל מעדכן על פיו את מסד הנתונים בדינמיות, אך בעוד לקליינט מותר לערוך רק את כתובותו האישית, הוא מוסיף שדות שהוא בכלל לא אמור להיות יכול לשנות (את שמם הוא מנחש או יודע דרך הבעיה של @yossiz).
בexpress למשל, מצוי שרואים קוד בסגנון הזה:

app.post('/update', async (req, res) => {
   if(req.body.id != req.seesion.user.id) return res.status(403);
   await connection.query('UPDATE users SET ? WHERE id = ?',  [req.body, req.body.id]);
   ...
});

הקוד הזה שהוא ממש קסום מבחינת פשטותו, הוא פרצת אבטחה בה משתמש יכול לשנות כל שדה, כולל את הID (ל1 למשל ואז הוא בטוח מנהל...)....
ראיתי מלא קוד דומה בפרודקשיין! יש פה טענה קצת על ספריית mysql שעשתה חיים מידי יפים בלי שום התרעה או אזהרה בתיעוד, אבל בnosql המצב הרבה יותר חמור.
בנוסף, בגלל שאין טיפוסיות קשוחה בJS המשתמש יכול לנצל את זה ולשלוח טיפוס שמצד אחד ייתמך במסד נתונים כדי שלא תהיה שגיאה בהכנסה או העדכון, אבל יהיו לכך השלכות לא טובות לגבי הלוגיקה בהמשך. אפילו מחלקה בנויה יפה בtypeScript לא תעזור פה שהרי בזמן ריצה הוא JS והוא מסכים הכל.
יש ספריות לזה, כמו express-validator אבל מי משתמש בה ביחס לכלל? זה אחת הבעיות של הטכנולוגיות המדליקות והחופשיות, אין שמה נורמות בסיסיות מרוב שרוצים לתת את ההגה למפתח.
מאמרים על Mass Assignment בנוד:
https://snyk.io/blog/avoiding-mass-assignment-node-js/
https://knowledge-base.secureflag.com/vulnerabilities/inadequate_input_validation/mass_assignment_nodejs.html

צרי להוסיף "או שווה למחרוזת ריקה".
הפכתי לך את התנאי כי לדעתי זה יותר קריא:

IIf([שם פרטי] IS NULL OR [שם פרטי] = "", "", "שם פרטי:" & Chr(13) & [שם פרטי] & Chr(13))

יש לציין שChr(13) נצרך לקפיצת שורה, אם אתה רוצה סתם רווח כתוב ככה:

IIf([שם פרטי] IS NULL OR [שם פרטי] = "", "", "שם פרטי: " & [שם פרטי])