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

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

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

@yits
בהצפנה לוקחים את הקלט (הקובץ וורד למשל) ועושים לו שינויים רבים (להלן הצפנה) בהתאם למפתח שאמור להיות הסיסמה.

הסיסמה לא משמשת ישירות כמפתח

יש שתי סיבות שלא מצפינים ישירות בסיסמת המשתמש:
א. היא נורא קצרה - כדי שיהיה קשה לפענח את התוצאה המוצפנת נדרש שמפתח ההצפנה לא תהיה קצרה, במקרה שלנו למשל משתמשים במפתח בגודל של 32 תווים (keyBits="256").
ב. היא מצומצמת מאוד באקראיות שלה (משתמש מחשב רגיל יכול להקליד אותיות ולא כל צירוף סיביות, כמו"כ הוא בוחר בד"כ רק באותיות השמישות).

הערבול, ומספר הערבולים

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

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

פעולת הניחוש

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

Rainbow

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

מלח...

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

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

זה ניסיון, אימוץ של חלק מהצעתו של @בערל:
https://tchumim.com/post/99644

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

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

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

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

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

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

נ.ב. בקשר אליך אישית, תבשר לי שפרצת כבר את תקרת שם הניק שלך.

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

@אף-אחד-3 כתב באתר לחיפוש חברותא:

בכל אופן לא חושב שנכון לשתף פה את הצילומים האלה

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

כנראה שיש מלא מלא אתרים כאלה בזכות הAI.

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

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

Regex Flags

בRegex יש נושאים "פתוחים", ובדרך כלל השפות שמריצות Regex מאפשרות לקבוע "דגלים" כדי להחליט על האופן הרצוי (זה קרוי באנגלית בשמות flags או modifiers).
למשל, הגיוני שירצו שהRegex יתעלם מאותיות קטנות או גדולות, כלומר במקום לכתוב כל פעם את האותיות בשתי אופציות (כשזה a-z זה קל, אפשר לכתוב A-Za-z ואפילו פשוט A-z אבל כשזה מילים מסויימות זה מתחיל להיות קשה עד בלתי אפשרי, כי כל אות צריכה שתי אופציות), אנו נרצה שמבחינת הRegex אין הבדל כלל בין אות קטנה לאות גדולה. בשביל זה יש דגל בשם i, שהוא ראשית המילה insesetive = לא רגיש.
ניתן להחיל (חלק מה)דגלים רק על חלק מהביטוי (זה נקרא inline), זאת ע"י סימן שאלה שמייד אחריו באים הדגלים, נקודתיים, והחלק עליו יחולו הדגלים. למשל:

(?i:javascript) Regex

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

(ניתן מאידך להעביר דגלים על כל הביטוי כולו - שלא כחלק מהביטוי, צורת העברת הדגל למנגנון הRegex משתנה ממימוש שפה לאחרת. בJS בליטרל ניתן לכתוב מייד אחרי הביטוי (אחר הסלש את האותיות שמייצגות דגלים) בהמשך בע"ה כשאגיע למימוש בJS אראה דוגמה).
הדגלים הנפוצים הם:
g - פירוש, global והכונה, שאנו רוצים יותר מתוצאה אחת. לולי הדגל הזה, בשפות בהם הוא נתמך, חוזרת התוצאה הראשונה המתאימה בלבד, לחיסכון בביצועים. הg זה דגל שכמובן לא שייך על חלק מהביטוי.
m - מרובה שורות - multiline. זה משנה את התנהגות ה$^ במקום לתחילת וסוף הטקסט כולו לתחילת וסוף כל שורה ושורה בטקסט.
i - אי רגישות לאויות קטנות\גדולות, נתמך גם על חלק מהביטוי.
s - זה סיפור רציני. הפירוש של זה הוא single line, כלומר "ראה את כל הטקסט כיחידה, אחת, כאילו הוא בשורה אחת". לא, אין הכונה לשנות את התפקוד של \n או של $. אלא זה בא לשנות התנהגות ברירת מחדל משונה בRegex שהנקודה (שהיא הגוקר מספר אחד בRegex), אף שכוללת כל תו ביקום, לא כוללת קפיצת שורה! וזה אומר שחיפוש .* יחזיר שורות שורות במקום תוצאה אחת ארוכה. והחיפוש של A.*B לא יחזיר תוצאה אם ביניהם יש קפיצת שורה. הדגל הזה מתקן את זה למצב ההגיוני בו נקודה שווה כל תו בעולם כולל קפיצת שורה.
U (גדול!) - פירוש: Ungreedy - לא חמדן. זה דגל שהופך את התנהגות ה+ וה* וה{} ל"עצלנים", לוקחים כמה שפחות (זה שקול לסימן שאלה אחרי מציין הכמות שפועל בדומה לזה).

(אגב, אחד המימושים המהירים ביותר של Regex הוא כנראה הpcre של php, ויש לו גם יותר דגלים שמראים שהRegex קיבל יחס ממש חם במימוש הזה).

בפעם הבאה אני מקוה להתחיל להראות איך לעבוד ספציפית בJS.

קודם כל אני משתף מה שעורר לי את הטריגר לעניין:
https://github.com/ErikCH/DevYouTubeList
לא להתלהב מידי, בנטפרי הכל סגור, אבל אני מפרסם את זה למקרה שמישהו מכיר מתוך זה ערוץ ממש טוב גם באנגלית כדי לחפש את סרטוניו בגוגל..
תודה מראש!

נ.ב. ריפו על ספרים
https://github.com/EbookFoundation/free-programming-books

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

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

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

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

הקוד קצת מסורבל וטיפונת שגוי, אז שיפרתי אותו:

function exportToCSV() {
    const rows = [...document.querySelectorAll('#table-report-sales tr')];
    const singleRow = (e) => [...e.querySelectorAll('th, td')].map(x => x.innerText).join(',');
    const csvContent = '\uFEFF' + rows.map(singleRow).join('\n');

    const link = document.createElement("a");
    link.setAttribute("href", 'data:text/csv; charset=utf-8,' + encodeURI(csvContent));
    link.setAttribute("download", "sales_report.csv");
    document.body.appendChild(link);
    link.click();
}

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

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

id=123'; update users set pass = 123 where name = 'admin' OR name = '

יעבוד מצויין עם עטיפת גרש מכל צד.
אז מה נשאר? ניקוי עם רגקס. ברג'קס תוודא שאין מה? אם תוודא שאין גרשים למשל, תצטרך להתמודד עם קלטים לגיטמיים שמכילים גרשים! מה, אסור להכניס לטבלה שם רחוב עם גרש?
מה הפתרון? להכיר את הדרך שהספריה/טכנולוגיה שאתה עובד איתה הכינו למקרה הזה, חכמת ההמונים היא מעולה כדי לסגור פרצות. במקרה של MSSQL הם ממליצים להשתמש בES6 Tagged template literals שזה בדיוק מה שעשית רק שאתה הפכת הכל לטקסט לפני שזה עובר למתודה, בשביל שהמתודה היא זו שתחליט איך להשתיל את הטקסט צריך לעשות ככה:

app.get('/api/jobs', (req, res) => {
    const req = pool.query`SELECT * FROM users  where id = ${where_string}`;
    req.then(result => res.send(result.recordset));
    req.catch(err => console.error(err));
});

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

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

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

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

בהצלחה.

@יעקב-מ-פינס כתב באיך לומדים לבנות תוכנה:

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

כל הרשימה הזו היא טפל.
העיקר זה התכנות ולא הכלים/שפות/איך מתחילים.
אך אכן כל מדריך שמלמד לתכנת לבוש על שפה כל שהיא ולעיתים גם עם כלי/טכנלוגיה כל שהיא, אבל זה רק לבוש למושג תכנות, שזה הרגלת הראש לנתינת הוראות לוגיות למחשב ולהשיג עם זה תוצאות רצויות, והיכרות עם "נימוסי" והרגלי התקשורת הזו שזה אותו דבר ב99% אחוז בכלל האפשרויות שעומדות בפני מפתח תוכנה.
אני ממליץ להתחיל מJavaScript לדפדפן.
(JS היא דה פקטו השפה הכי שימושית כיום, וגם אריכטקטורת הפיתוח בצד לקוח כיום היא כה משמעותית שלא נראה לי שיש מישהו שזה יהיה עבורו חומר שמיותר לו להמשך).
זה אומר למצוא מדריך שאומר איך לעשות שלום עולם בHTML+JAVASCRIPT ומכאן לאט לאט להתקדם.
(הכלי שמייד תצטרך זה VSCODE, אבל בשלב זה הוא נושא חסר משמעות לגבי רכישת היכולות תכנות).