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

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

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

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

פורסם במקור בפורום CODE613 ב13/02/2014 12:21 (+02:00)

@דוד ל.ט.

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

את זה כתבתי בהדועה שלי. ע"י סניפר אתה יכול לראות כל מה שזז.

וכמובן שיש גם אסמבלר...

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

פורסם במקור בפורום CODE613 ב13/02/2014 10:24 (+02:00)

@דוד ל.ט.

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

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

אם אני מבין, אתה משתמש רק בSP ולא ח"ו בדאטאסט ודומיהם, אחרת יש גישה לטבלה גם בדאטאסט, לא?

נתחיל....

WPF וWINFORMS:
בWPF יש רפלקטור שיכול להוציא את קוד המקור.
יתרה מכך, בדוטנט בד"כ הקונקשיין נשמר בAPP.CONFIG.

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

בא ונראה איפה אבטחת המידע:
נניח שהID של היוזר הוא 2 - ועכשיו בא לו לקרוא את הנתונים שרק יוזר שהID שלו הוא 1 יכול לקרוא,כל מה שהוא צריך לעשות זה:

1. להעתיק את הקונקשיין.
2. להעתיק דרך הרפלקטור את משפט הSP.
3. להריץ את זה ממקום אחר ולשלוח בID של היוזר 1 במקום 2. (יש לו הרי שליטה על כל מה שזז.)

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

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

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

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

בא ונראה איפה אבטחת המידע:

1. אני לא שומר שם משתמש וסיסמא בטבלה המקושרת. מי שיצליח לחלץ את הקונקשיין - יהיה לו רק את השרת + שם הDB. (כל השאר לא רלוונטי בחיבור)
2. החיבור לטבלאות המקושרות מתבצע אחרי הכניסה -- עם שם המשתמש והסיסמא של המסד, ואחרי שאני מוודא שאין לו גישה לטבלאות (כולל שהוא לא יכול להציג אותם ע"י F11)
3. כל הקוד חסום וסגור ללא אפשרות רפלקטור.

כל מה שכתבתי כאן זה לגבי חיבור רגיל של ODBC עם אקסס. לגבי הדוגמא שהעלתי לעיל, אני מוסיף גם את הסעיף הבא:
4. אין טבלה מקושרת. אין איך להוציא את הקונקשיין. כי הוא יושב בתוך הקוד. (לגבי הפחד שמישהוא יריץ את הפונקצייה מבחוץ [זה אפשרי] - אני חושב להכניס אצלי עוד פרמטר של סיסמא פנימית, כדי שאף אחד לא יוכל לבצע את החיבור מבחוץ. [אני עושה את זה כיום כך בריענון של השרת -- בסעיף 2])

אגב, האובייקט הנ"ל זמין גם בדוטנט וגם בC++ וכו'

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

לך אולי זה לא אכפת, אבל יש לקוחות שהמידור במשרדם קריטי.

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

מתנצל על התגובה הארוכה
ClickOne

פורסם במקור בפורום CODE613 ב13/02/2014 00:30 (+02:00)

@דוד ל.ט.

אני לא בסוגיא אז אל תטרח להסביר לי עוד.
הדברים ששאלת:

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

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

@דוד ל.ט.

דרך העבודה עם SP זה לא לכתוב את שמו כמו שאילתה, הוא אומר להיות אלגנטי יותר, אני לא יודע עד כמה אקסס תומך בזה, יעויין: http://support.microsoft.com/kb/185125
בקשר להרגל לSQL הרגיל ובקשר לגמישות אתה חופשי להמשיך זאת בצד המסד, תוך עריכת הSP.

אקסס לא החשבון כאן, כי הכל עובר כמות שהוא לשרת.
@דוד ל.ט.

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

לא נריב. ממש לא היקף מזערי. ואני ממש לא זול בעלות לשעה ללקוח.

פורסם במקור בפורום CODE613 ב12/02/2014 19:13 (+02:00)

@דוד ל.ט.

ClickOne אם כבר כותבים את השאילתה וקוד, עדיף להפעיל SP מאשר שאילתה.

לא בחרתי בSP מכמה סיבות.

1. לSP אם יש פרמטרים צריך לבנות COMMAND וזה כבר לא גנרי.
2. רציתי להיצמד לאקסס ככל שניתן, כדי שברמה העקרונית תהיה אפשרות ברוב המקרים לשלוף את קוד הSQL ממקור הרשומה של הטופס. (אני זוכר שיש איזה פונקצייה שיודעת "לתרגם" את הפרמטרים הפנימיים של אקסס לערכים מוחלטים [זכרתי משום מה שזה Eval אבל זה לא.]), ואז תהיה אפשרות רק לתת את הטופס והקוד יעשה הכל.
3. אני לא בטוח שיהיה אפשר אח"כ לערוך את הרשומות כטופס רגיל כמו בדוגמא (לא ניסיתי). אם לא יהיה אפשר, אין טעם לעשות את זה. כל הרעיון של הקוד הזה הוא הגמישות בעריכת הרשומות כמו באקסס רגיל.
4. למתכנתי אקסס (ואני בתוכם) יש נטייה לכתוב קוד SQL בקוד, שם לא יעזור SP.

@דוד ל.ט.

זה יותר בטוח, יותר מהר, ויותר ממודל (המסד האמיתי מהתצוגה).

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

במידה ואכן צריך להריץ SP אפשר בהחלט להשתמש בפונקצייה השנייה שהבאתי בקובץ - שמריצה כל קוד SQL אפשרי על השרת.

@דוד ל.ט.

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

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

אני מאד מבין את הרצון שנעבור למערכות "מתוחכמות יותר", אבל תבין שכשיש לי פרוייקט עם 40 מודולים , 115 טפסים, למעלה מ80 טבלאות, ולא יודע כמה שורות קוד שכולו מחובר דרך ODBC, אל תצפה שאני יעביר את הפרוייקט לWPF (אין סיבה שהלקוח יסכים לשלם :x ) והצורך לחפש דרכים יותר זריזות וממילא יעילות בטפסים ובדוחות הוא הכרחי.

פורסם במקור בפורום CODE613 ב12/02/2014 18:14 (+02:00)

@ClickOne

חסרונות:

א"א להוסיף חדש אם זה שאילתא JOIN עם 2 טבלאות או יותר, לעומת אקסס (כולל ODBC באקסס) שזה אפשרי.

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

Me.UniqueTable = "TblClsRoom"

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

SetSqlServerRs Me, "SELECT TblClsRoom.IDClsRoom, TblClsRoom.CName,SumProfitPay, TblClsRoom.CTime, TblPayStub.IDPayStub, TblPayStub.psMon, TblPayStub.SumMoitalPay FROM TblClsRoom INNER JOIN TblPayStub ON TblClsRoom.IDClsRoom =  TblPayStub.IDClsRoom WHERE (((TblPayStub.psMon)='1-1-14'));"
Me.UniqueTable = "TblClsRoom"

פורסם במקור בפורום CODE613 ב12/02/2014 00:02 (+02:00)

בהמשך למה שארכיטקט כתב כאן:
@ארכיטקט

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

חשבתי רבות מה ניתן לעשות, כי טענתו אכן הייתה טענה טובה, והרעיון שהוא הציע היה נשמע טוב ויעיל.
בסוף,אחרי מחשבה רבה, יצא לי משהו, ורציתי לשתף אתכם....
הקובץ:
Odbc2Sql.zip

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

SetSqlServerRs Me, "SELECT * FROM TblStudent;"

כמובן ש: "SELECT * FROM TblStudent;" זה טקסט הSQL שנשלח לשרת.
שימו לב שמה שנשלח לשרת, צריך להיות קוד נכון בSQL ולא קוד של אקסס (בטבלאות רגילות אין הבדל)

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

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

**עריכה: הבעייה שא"א להוסיף נפתרה.
צריך להוסיף אחרי הפונקצייה שורה שבה קובעים מהי הטבלה הראשית.

Me.UniqueTable = "TblClsRoom"

לפרטים בהרחבה - עיינו בהודעה הבאה.**

יש רעיונות לשיפורים?

ד"א יש בקובץ פונקצייה נוספת שהיא:

ExecSQL ("INSERT INTO TblStudent (Name) VALUES (N'foo'))

פונקצייה זו מאפשרת להריץ כל קוד SQL אפשרי בשרת.

ותודה לארכיטקט על הרעיון!!!

פורסם במקור בפורום CODE613 ב11/02/2014 16:50 (+02:00)

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

עריכה:
ארכיטקט: אתה יכול בבקשה להעלות את קטע הקוד של ההוספה שנכשל בתוך הפרוצדורה?

פורסם במקור בפורום CODE613 ב09/02/2014 11:25 (+02:00)

@ארכיטקט

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

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

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

פורסם במקור בפורום CODE613 ב09/02/2014 02:12 (+02:00)

אתה מכניס הכל במכה, או עם לופ?
הייתי הולך על משהו בסיגנון של On error resume next בVB. (אני לא בטוח שזה קיים בSQL במתכונת הזו)
אבל מה שבטוח קיים זה בסגנון TRY של דוטנט.
דוגמא לTRY עם יצירת שגיאה בחילוק ב0:

BEGIN TRY
    -- Generate divide-by-zero error.
    SELECT 1/0;
END TRY
BEGIN CATCH
    -- Execute error retrieval routine.
    
END CATCH;

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

בנוסף:
הטבלה שאליה אתה מוסיף היא זמנית או קבועה?
אם היא זמנית אז לא נורא שתעשה בסוף SELECT DISTINCT ואז תוסיף לקבועה או תעשה מה שבא לך עם הנתונים. אם היא קבועה, אז באמת זה לא כ"כ בא בחשבון.

פורסם במקור בפורום CODE613 ב09/02/2014 01:30 (+02:00)

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

וכל זה כמובן בלי להתייחס לדיון המרתק שם עם דוד ל.ט. על אבטחה וSP <!-- s8-) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8-)" title="מגניב" /><!-- s8-) -->

פורסם במקור בפורום CODE613 ב07/05/2014 12:12 (+03:00)

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

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

select * from master..sysprocesses where spid > 50 and spid = @@spid

נראה לי שאחד השדות שם זה המזהה הייחודי של החיבור.

פורסם במקור בפורום CODE613 ב06/02/2014 13:07 (+02:00)

@ארכיטקט

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

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

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

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

נכון...
אבל במה שהוא מחזיר אתה לא יכול לעשות שינויים, וזה מה שהכי מעצבן. את הארץ תראה, ושמה לא תבוא.....
אגב, יש בSQL SERVER משתנים גלובליים? וא"כ - אפשר לשייך משתנה גלובלי לסש'ן? (כמו בווב)? - אם זה אפשרי, זה יכול להיות פיתרון מצויין לקוד המדהים שהעלת (וכאן המקום לפרגן על הרעיון וגם על השיתוף!! [בהחלט לא דבר פשוט שמישהו מעלה קוד כ"כ מושקע שעבד עליו] - כי באשכול ההוא עדיין לא הספקתי לצערי) -- רק ששם לא הייתה אפשרות לשמור את הID של המשתמש הנוכחי, כי לא ידעת מי הוא. (היית צריך להתבסס על שם המשתמש בווינדוס אם אני זוכר נכון) - אם יש משתנה גלובלי, או אפילו SessionID של כל חיבור, אפשר לשלוח מיד אחרי ההתחברות משתנה גלובלי דרך שאילתת מעבר, ואז לשלוף את זה בטריגר)

פורסם במקור בפורום CODE613 ב06/02/2014 12:35 (+02:00)

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

פורסם במקור בפורום CODE613 ב09/02/2014 12:12 (+02:00)

@רחמים

מה זה SoapSDK ? גם מי שעובד עם פלא קארד מול ווב סרביס צריך את זה?

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

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

יש דוגמא לאקסס כזה?

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

אני מניח שכיום באירגון שאתה עובד איתו עובדים בשיטה זו:

1. יש קובץ / דף שבו כתובים מספרי האשראי והתוקף (ואולי גם היום לחיוב האשראי)
2. פעם בחודש (או יותר) יושב מישהו ומחייב דרך המכשיר את כל האנשים.

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

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

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

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

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

פורסם במקור בפורום CODE613 ב09/02/2014 00:30 (+02:00)

בעבר הצורה כדי לחייב אשראי הייתה שיש את אשראי 96 על המחשב ואז אתה מייצר קובץ במבנה מסויים במקום מוגדר,מפעיל תוכנית מסויימת וזה משדר ושם את התוצאות בקובץ אחר. אח"כ שב"א החליטו שבשביל לעשות את זה אתה צריך להיות לפחות עם 100 לקוחות שרוצים לסלוק אשראי, ולקנות 100 רשיונות (לא עזר כל התחנונים שלי ש"איך אני יביא 100 לקוחות אם את הראשון הם לא נותנים לי")
בשלב מסויים חוק האשראי החדש אסר על שימוש באשראי 96, והדרך היחידה כדי שזה יהיה מאובטח זה לעשות תקן DDS (שעולה בסביבות כמה מאות אלפים בשנה), או לשכור שימוש דרךווב סרביס כמו פלאכארד [שמממשים את התקן]. (בערך 60-80 ש"ח בחודש) - מי שמשלם את זה זה הלקוח ולא אתה.

לינק לדוגמא של פלאכארד. (גם אני עובד איתם ) - לצערי בפורום ניתן להעלות קבצים רק עד 2 MB. (אפילו שאני זוכר שכתבו שהעלו את זה ל5 MB)
שים לב שצריך להתקין את SoapSDK (גם אצל הלקוח)

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

פורסם במקור בפורום CODE613 ב06/02/2014 12:26 (+02:00)

אני מצרף דוגמא שכתבתי בעקבות השאלה. (לאחראים: נשמח אם תאפשרו גם את הסיומת accdb בהעלאת קבצים <!-- s8-) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8-)" title="מגניב" /><!-- s8-) --> )
השאילתא לא תלוייה במיון ולא בסינון. (גם אם נסנן רק תשלום אחד זה יראה איזה תשלום מתוך כמה)

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

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

Database1.zip

פורסם במקור בפורום CODE613 ב09/02/2014 01:40 (+02:00)

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

Private Function RefreshLinks(strFilename As String) As Boolean
' Refresh links to the supplied database. Return True if successful.

    Dim dbs As Database
    Dim tdf As TableDef

    ' Loop through all tables in the database.
    Set dbs = CurrentDb
    For Each tdf In dbs.TableDefs
        ' If the table has a connect string, it's a linked table.
        If Len(tdf.Connect) > 0 Then
            tdf.Connect = ";DATABASE=" & strFilename
            err = 0
            On Error Resume Next
            tdf.RefreshLink         ' Relink the table.

If err <> 0 Then
                RefreshLinks = False
                Exit Function
            End If
        End If
    Next tdf

    RefreshLinks = True             ' Relinking complete.
End Function

בהצלחה!!

פורסם במקור בפורום CODE613 ב04/02/2014 20:37 (+02:00)

@שמואל

@ClickOne

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

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

@shsh654

נשמח לשמוע מClickOne כיצד אכן עובד לוח הסילוקין שלו - שורה במקרה של שינוי והקוד 'עובר' דרך שם לפני הביצוע?

לא תמיד אני משתמש בלוח סילוקין. רק בשכ"ל ובגמ"ח. (בינתיים <!-- s8-) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8-)" title="מגניב" /><!-- s8-) --> )
וגם בשכ"ל הלוח סילוקין לא לא אינסופי. אלא ל12 החודשים הקרובים בלבד. (ז"א יש ללקוח מקום לבנות לכל שנתון את ה"שירותים" שהוא מספק לשנה זו - זה יכול להיות שכ"ל חודשי, ביטוח,, נזקים חד פעמיים וכו') הלקוח מגדיר סטטוס לכל שירות, האם הוא אוטו', ידני, וממה הוא נגזר שכ"ל, ביטוח וכו, וכן האם השירות פתוח [עדיין לא התחיל], פעיל, או נסגר.
יש בנייה חד פעמית לכל המוסד בשנתון של לוח הסילוקין, שבו מוגדרים השירותים שהתלמיד מקבל מהמוסד.
בכל חודש הלקוח עושה בניית הו"ק, ואז התוכנה בודקת אם יש שירות שמוגדר לתשלום בהו"ק שעדיין לא שולם, ואם כן היא מייצרת חיוב לתשלום.
כמובן שגם מי שמוגדר לתשלום בהו"ק, אם ההורה יבוא וישלם בשיקים, ברגע שיוציאו לו קבלה, התוכנה תבדוק ותשייך לו את התשלומים לאותם ה"שירותים" שהוא קיבל מהמוסד. - בדוגמא המצולמת להלן אפשר לראות שהייתה חזרת הו"ק, וההורה הגיע לשלם בשיק. (לגבי השורות הנוספות בתמונה של החזרת ההו"ק וכן של העמלה זה עם שאילתת UNION וכבר הסברתי ע"ז במקום אחר)

מצ"ב צילום מסך לדוגמא של לוח סילוקין לתלמיד

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

@שמואל

@ClickOne
ובנוסף, אני חושב שיש לאפשר יותר מהו"ק אחת פעילה לכל תורם. נניח שהוא רוצה להביא תרומה מהחשבון השני שלו??

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

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

פורסם במקור בפורום CODE613 ב09/02/2014 01:08 (+02:00)

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

אני משתמש בגישה הבאה:
טבלת הו"ק - מכילה את פרטי ההו"ק.
טבלת תרומות/עסקאות - מכיל את כל העסקאות (שמואל: שים לב: אני מצרף את 2 הטבלאות ל1, וטבלת המשנה שלה היא ההו"ק שתיגבה, או האשראי וכו')
טבלת העברות מס"ב
טבלת תנועות שיקים, מזומן, ואשראי
טבלת כרטיסי אשראי. (מסומן כטוקנים, כי אסור לשמור מספרי אשראי [גם לא מוצפנים])

כל שורה מההו"ק קשורה לשורה בעיסקאות.
כל שורה בהעברת מס"ב קשורה להו"ק שלה + לID של העסקה
כל שורה באשראי קשורה לטבלת העסקה + לטבלת התנועות אשראי. הסיבה: לכל אשראי יכולה להיות יותר מתשלום אחד כשמדובר על הו"ק באשראי [עם טוקנים כנ"ל].
בכל חודש כשהתוכנה מחייבת הו"ק באשראי, היא מוסיפה שורה אחת לטבלת התנועות ושומרת את הID של האשראי + הID של העסקה.

במס"ב - כנ"ל.

כשאני רוצה להוציא דוח משולב אני משתמש בUNION.

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

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

**לארכיטקט:**אני מסכים איתך שאין סיבה לכתוב את תאריך הסיום, אני בכל מקרה נוקט בגישה של לכתוב 999 במקרה של בלתי מוגבל.

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

פורסם במקור בפורום CODE613 ב04/02/2014 13:07 (+02:00)