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

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

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

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

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

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

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

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

@אלף-שין הפתרון שלך יפה, אבל הם צודקים שהענישו אותך, כי אין ספק שיש דרכים להשיג אייפי של מישהו, אבל השאלה שם הייתה איך למצוא את זה לפי מייל שהוא שלח או שתשלח אליו. הרעיון שלך מתעלם מהקושי המרכזי, איך לגרום לשני לעשות מה שמתחשק לך שהוא יעשה.
זה כמו הסיפור על הרשלה שמכר חומר להשמדת ג'וקים. כשהתלוננו הלקוחות שזה לא עובד אז הוא שאל אותם האם הם פעלו לפי ההוראות, הלקוחות שאלו מה ההוראות ואז הוא הסביר להם שיש לתפוס את הג'וק ולדגדג אותו בבטנו, ואז כשהפה שלו פתוח להכניס לו את החומר לפה ולסיום לדפוק עליו חזק עם נעל בית...
הרעיון שלך הוא שליחת פיתיון: "בא תיכנס למייל הזה עם הסיסמה הזו, אתה חייב לראות מה יש שם" באותה מידה אתה יכול לומר לו שכדאי לו להקריא מה כתוב בגוגל בחיפוש 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 [שם פרטי] = "", "", "שם פרטי: " & [שם פרטי])

@יהודי-טוב כתב בהשמעת audio בתגית audio כשהמקור הוא קובץ להורדה (ימות המשיח):

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

זה נראה פרשנות שלך לבעיה.
היה עוזר לראות שגיאות קונסול או רשת.
בקוד שלך חסר מרכאות כפולות מסביב ל{src}.

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

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

בשביל לזהות מה ואיך הדפדפן שולח לשרת בעת ובפרט בסיום המילוי,
עליך לפתוח את כלי המפתחים, לעבור ללשונית Network - רשת, ושמה לנקות את הבקשות הקודמות על ידי לחיצה על סמל האין כניסה, ולוודא שהסמל העגול שלידו מסומן באדום - כלומר מתעד פעולות רשת.
כעת תמלא את הטופס, ושים לב לבקשות. יש בקשות לא רלוונטיות, כמו רשימת ערים או תמונת כפתור שעלולים להיות תוך כדי, אבל יש בקשות יותר חשובות כמו בקשת טוקן וכדומה שעלולה להתברר כמעניינת.
הרגע הכי חשוב זה רגע שליחת הטופס, שלכאורה רק הוא נצרך. צריך לוודא לפני הלחיצה דבר ראשון שהאפשרות Preverse log מוסמנת שלא יעלם תיועד בעת ניווט מחדש לדף אישור/תודה באם ישנו. צריך לשים לב גם מה השורה האחרונה, כדי שיהיה קל לראות איזה פעילות יצרה הלחיצה.
כעת אתה לוחץ, בד"כ זה יוצר שורה שמייצגת בקשת POST, ובליחצה על השורה בכרטסת Payload (לא יודע איך זה בעברית) יש את המידע שהדפדפן שולח לשרת. בכרטסת Response יופיע תשובת השרת. נקודת המוצא היא שזו השורה היחידה הנדרשת, אז עליך לנסות לחקות אותה עם כלים תכנותיים, כמו fetch בקונסול של הדפדפן או כל דרך אחרת. אם זה עובד מוטב, אם לא צריך לבדוק לאט לאט את הpayload ואת כותרות הבקשה, האם יש בהם מידע שמסגיר עקבות קודמים כמו עוגיות וכדומה, ולפתור בעיה בעיה עד שהכל עובד.
מעקב הכונה שהשרת עלול לדחות בקשות שלא עולות בקנה אחד עם בקשות קודמות, ולעיתים יש אפילו תחכום לוודא שהבקשות היו בסדר/קצב/אופן אנושי, כשזה מגיע לבדיקות ברמה חריפה קשה לדעת את כל זה ולכן עוברים לאוטומציה של דפדפן שאז אתה עם הקוד פשוט מפעיל ברקע דפדפן שמשתדל לעשות כל מה שדפדפן רגיל עושה כמו אירוע מעבר עכבר וכולי.