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

@אביי כתב בשמירת מאגר מספרים וסיסמאות/טוקן בצורה מאובטחת:

@eido כתב בשמירת מאגר מספרים וסיסמאות/טוקן בצורה מאובטחת:

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

קריאה פשוטה לGetSession מחזירה את מספר המערכת

נכון, בדיוק לכן כתבתי שהטוקן מוגבל.

@אביי כתב בשמירת מאגר מספרים וסיסמאות/טוקן בצורה מאובטחת:

@eido כתב בשמירת מאגר מספרים וסיסמאות/טוקן בצורה מאובטחת:

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

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

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

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

@אביי כתב בשמירת מאגר מספרים וסיסמאות/טוקן בצורה מאובטחת:

@eido כתב בשמירת מאגר מספרים וסיסמאות/טוקן בצורה מאובטחת:

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

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

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

ודאי שזה לא טוב, אבל זו אופציה.

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

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

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

מה הדרך המקובלת לעשות?

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

@אביי כתב בבירור על מערכת סליקת אשראי מתאימה לאתר עם מודל מנויים:

@eido כתב בבירור על מערכת סליקת אשראי מתאימה לאתר עם מודל מנויים:

אולי רק מדווח בשנה הראשונה.

אתה מתכוון מדווח אחת לשנה למס הכנסה בלבד

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

@NH.LOCAL בתור עוסק פטור אתה לא מתעסק בכלל עם מע"מ או מס הכנסה, אולי רק מדווח בשנה הראשונה.

מי פנה אליך? הפנתי 2, לדעתי קשר הכי זולים.

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

כדאי לשאול אותם הכל כולל הודעות על ביטולים, למרות שלדעתי כולם עושים את זה.

@dovid אני שולף את שניהם אחד אחרי השני, לא אכפת לי שיהיה במכה אחת, אבל איך משתמשים בזה? איך אני רואה אם זה חדש או ישן?

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

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

טוב, אז זה הקוד החדש:
מציאת מודעות:

$sqlNew = "SELECT a.*
FROM appartments a
WHERE $where
  AND a.created_at >= ?
  AND NOT EXISTS (
        SELECT 1
        FROM apartment_reads ar
        WHERE ar.apartment_id = a.id
          AND ar.phone = ?
  )
ORDER BY a.created_at DESC";

$sqlOld = "SELECT a.*
FROM appartments a
WHERE $where
  AND (
        a.created_at < ?
        OR EXISTS (
            SELECT 1
            FROM apartment_reads ar
            WHERE ar.apartment_id = a.id
              AND ar.phone = ?
        )
      )
ORDER BY a.created_at DESC";

סימון כנקראה:

 $sql = "INSERT INTO apartment_reads (apartment_id, phone)
    VALUES (?, ?)";

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

FOREIGN KEY (apartment_id) REFERENCES appartments(id) ON DELETE CASCADE

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

@צדיק-תמים כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

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

@eido כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

חוסכת מהמאזין זמן ריצה כמו קאש שמושכים ממנו את המודעות

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

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

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

אולי חסרה לי הבנה ברעיון מאחורי ההצעה שלך.

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

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

@צדיק-תמים אין array...
השאלה כמה זה קריטי, זה לא יד2... לא מאמין שזה יהיה גדול בצורה משמעותית.

כתב בהסרת מודעות ממסד נתונים - מורכב להסביר בשורה אחת:

@צדיק-תמים הקוד הבא זה מה שהתכוונת?

$sqlNew = "SELECT *
FROM appartments
WHERE $where
AND created_at >= ?
AND alreadyRead NOT LIKE ?
ORDER BY created_at DESC";

$sqlOld = "SELECT *
FROM appartments
WHERE $where
AND (created_at < ? OR alreadyRead LIKE ?)
ORDER BY created_at DESC";
וזה מסמן כנקרא

$sql = "UPDATE appartments
SET alreadyRead = IF(alreadyRead LIKE ?, alreadyRead, CONCAT(alreadyRead, ?))
WHERE adId = ?";
$stmt = $conn->prepare($sql);
$stmt->bind_param("ssi", "%".$_REQUEST['phone']."%", $_REQUEST['phone'].", ", $_REQUEST['adId']);

@צדיק-תמים

@chv למה, היום בסליקה הישראלית את היכול לעשות הכל.

@Shmuel754 האמת זה רעיון מה שאתה אומר, אומנם לא הצלחתי להבין את כולו (אני לא חזק בתחום הזה), אבל מה שכן הבנתי, מראה על מערכת יותר חכמה.

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

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