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

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

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

@יוס כתב בסינון אתרוג חכם או חכמולוג:

יש פתרון לזה, או (וזה מה שעשיתי בינתיים) פשוט להסיר שם את התגית body?

ראשית כל לא הבנתי את הבעיה, ההשתלה על פניו לא הייתה אמורה לדפוק משהו.
שנית, מה שעשית בסדר גמור, אתה יכול להדפיס לדף תגית שורש כמו div ולא לשים מסמך תקני מלא, את הdir="rtl" אתה יכול לשים בתגית השורש.

@יעקב2 שני המוצרים ש@shraga הביא הם קוראים גם של כרטיסים חכמים.

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

הקושי עם כלים מחוץ לIDE (או ליתר הדיוק VSCODE שזה עורך טקסט מודרני ולא IDE) מהווים קצת ייתרון,
כי ברגע שזה בIDE אין סיכוי לעמוד בפיתוי לקבל את השינויים גם בחוסר ריכוז או אפילו בלי קריאה.
מאידך בIDE רואים כל שינוי ברור בצבע (לפני/אחרי) וגם אפשר לבצע ביטול וגירסאות גיט.
כיום VSCODE+COPILOT כוללים את הAgent שזה עורך קבצים מרובים ישירות בIDE.

@Sara-Rivka זה דקויות, כל אחד יענה משהו אחר.
nodejs + react זה בכלל לא "מסויים מאוד" זה מאוד רחב (react לבד זה 10 אחוז מהמשרות אם לא יותר), אם כבר פלאטר זה מסויים מאוד (לא שאני לא מכבד, יש כבוד).
.NET הרבה יותר חזק בתעשייה ובדרושים מאשר פייתון לפחות בארץ, בפרט כצד שרת לווב.

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

@nach כתב בMaPraqti: תובנות על vibe coding בבקשה :

אפילו עכשיו כשאתה משכתב את המערכת, אתה יודע בכלל שיש כלים חדשים יותר עבור ריאקט? כמו NEXTJS או דברים דומים שבנויים על תשתית של ריאקט או VUE ומפשטים תהליכים וקוד וSEO ועוד הרבה דברים וריאקט עצמו לבד (עם VITE...) כבר הרבה פחות שימושית בתעשיה! הרי הוא לא יגיד לך את זה, אתה תגלה את זה עוד חודשיים כשתרצה קידום בגוגל או שתרצה מערכת ניתוב קלה יותר או מבוססת משתמשים ועוד כל מיני דברים שברור שאפשרי בריאקט הרגיל ג"כ אבל הם פי אלף קלים להגדרה עם מטה פריימוורקס, הוא לא יגיד לך את זה עד שתשאל אותו "האם מומלץ לי X או Y".

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

זאת אומרת שהוויב קודינג לגמרי לא מחליף את הידע המקצועי (אולי זו משאלת לב..?)

פותח הנושא הוא @yossiz, אם כבר משאלת ליבו הפוכה (כמו שלך?).

@yossiz כתב בMaPraqti: תובנות על vibe coding בבקשה :

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

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

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

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

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

@one1010 @מד שימו לב שאתם לא בטעות נסחפים למשהו שלא עוזר לפותחת הנושא.

@avi-rz
מיותר החסימה, אתה לא צריך לעשות שום דבר מקורי.
אמנם אתה כן צריך לחייב סיסמה ארוכה וקשה (ואם זה מאוד רגיש ויש מקום לחשש אז לחייב Two Factor).
שים לב בexpress-session מקבל secret, שים שמה משהו רנדומלי.
ראה גם הערה בהמשך לגבי גיבוב הסיסמה - זה לא מוסיף אבטחה על האתר אלא מגן על סיסמת המשתמש.
עד כאן זה הטכניקה, וכפי שאתה רואה אין פה כמעט כלום. אז איך כל הזמן יש פריצות לאתרים? בגלל לוגיקה שגויה של מפתח, ודי במקום אחד לאורך כל היישום.
יש כמה סוגים עיקריים, אני שם לפי סדר התדירות לדעתי:
א. חוסר ביקורתיות על קלט משתמש. זה כולל כמה וכמה התקפות, אני ארחיב בהמשך.
ב. חוסר התבוננות על השלכות של פעולות, שמאפשרות למשתמש בהינתן מצבים מסויימים למצל אותם.
ג. מימוש בדיקת אבטחה בצורה לקויה או באופן לא מספק.
ד. טעויות של ממש ובאגים, שמשתמש הצליח לקלוט ולנצל.

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

א. חוסר ביקורתיות על קלט משתמש

זו הבעיה מספר 1 שאין מצב להינצל ממנה בלי אימון של חשיבה ביקורתית.

• sql injection קלאסי (שרשור טקסט) ופחות קלאסי שזה קצת הסעיף הבא).
• קלטים לא צפויים במבט של מפתח נחמד, אלא רק עם ביקורת קצת קרימינלית:
  למשל אתה מצפה לקבל מספר שלם בין 1 ל10, ואפילו מוודא את זה עם פונקציה, ואתה גם מוודא שלא מדובר ב5 כי זה צריך הרשאה משמעותית יותר. אבל המשתמש החכם שם 4.9 שזה לא 5... בהכנסה למסד זה מתעגל ל5 - מספר שלם בגלל איזה ספריה כשרונית כל שהיא שמתאימה את הקלט לשדה שהוא מסוג מספר שלם.
  דוגמה גרועה יותר זו בדיקה טקסטואלית על קלט שבסוף מספרי אפליקטיבית - param != '5', ואז המשתמש שולח לך 5.0 או 05...
• קלטים קיצוניים שגורמים לבאג/שגיאה שמבחינה לוגית מביאה למשתמש ייתרון שלא אפשרת לו בcontrole flow. למשל שמת try אבל הקוד ממשיך אח"כ, בלי החלק האבטחתי שבתוך הtry (זה לא קשור לקלט משתמש דוקא, כי יש עיקרון: כל try עיוור, שמאפשר להכיל כל שגיאה, הוא פוטנציאלית בעיית אפליקציה ולעיתים בעיית אבטחה. לא לעשות try-catch בלי שיודעים מה תהיה השגיאה).
  למשל אתה מקבל מייל ומוודא עליו משהו, אבל לא חשבת שיכול להיות שהמשתמש ישלח מחרוזת באורך של מגה... אבל לא היה קורה כלום אם לא שבעודף תבונה שמו try שמה על משהו, ובחוסר תבונה לא דאגו שכל catch לא צפוי יזרוק שוב שגיאה (כל המפתחים כמעט כולל עבדך הנאמן מוותרים על הרעיון...) הקוד בהמשך הוא יכול להיכשל (הכי טוב) ואולי להשאיר תוצאות לא רצויות (פחות טוב) ולפעמים לאפשר משהו שלא רצינו (פירצת אבטחה).

ב. חוסר התבוננות על השלכות של פעולות שאפשרו למשתמש לבצע

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

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

ג. מימוש בדיקת אבטחה בצורה לקויה או באופן לא מספק.

• ניסיון מימוש אבטחה מקורי/אישי, כשמדובר במקרה קלאסי ובפרט סבוך.
  למשל טיהור קלט פרמטרי SQL על ידי החלפות או עטיפה במרכאות וכדומה, במקום טכניקה של פרמטרים.
  טיהור HTML עם regex וכדומה, במקום שימוש בספריה עם שימוש מסיבי בתעשייה.

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

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

אדגיש קודם שבמקרה הזה התשובות שאני אומר הם לא דעתי האישית או נטיית דעה/לב, אלא עקרונות מאוד חד משמעיים שמקובלים בכל מערכת נורמלית.
א. טבלת users אחת. role בטבלה או בטבלה נפרדת, אני מעדיף נפרדת עם אפשרות של יותר מrole אחד למשתמש.
ב. הסתרת נקודת קצה לא מועילה כלום באבטחה. זה נכון שיהיה קשה לתוקף לדעת, אבל זה לא נחשב שעשית אפילו מילמטר מבחינת אבטחה.
אם האבטחה שלך היא ללא פגם, לא היית מרגיש צורך בסניף המסכן הזה, ולהיפך, אם יש לך קצת הישענות על הסתרת נקודת הקצה של המנהל, יש פגם באבטחה שלך. זה צריך להיות מאה אחוז גם אם כל העולם יודע.
(יש אמנם עיקרון של ערפול כאבטחה (Security through obscurity ראה פה), אבל הוא עיקרון מצומצם שאף פעם לא צריך לעמוד בשיקולי ארכיטקטורה, ובשום אופן לא להיות אפילו סניף לאבטחה. זה אולי אולי תוספת להוסיף למהדרים אחרי שהמערכת 100 אחוז, אני בעד לוותר על ההידור שמביא לידי קולות).
אם אתה רוצה להתייעץ על איך ניתן לפרוץ למערכת שלך והאם האבטחה שלך מספיקה, זה נושא מעולה לדיון.

@YK כתב בהתקנת כרום בגירסא נמוכה לצד גירסא מתקדת יותר.:

המטרה היתה דפדפן שמאשר/סומך על הגדרה של 'X-Frame-Options'.

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

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