પ્રતિનિયુક્ત ઍક્સેસ
કોઈ ડેવલપરને શામેલ કરો, તમારા એકાઉન્ટન્ટને બિલિંગ સોંપો, ક્લાયન્ટને તેમની પોતાની સાઇટ્સ માટે ફક્ત વાંચવા માટેની ઍક્સેસ આપો, અથવા અમારી સપોર્ટ ટીમને સમસ્યા તપાસવા દો. દરેક મંજૂરી એ નિર્ધારિત પરવાનગીઓ ધરાવતી ભૂમિકા છે, જે સંસ્થા પૂરતી સીમિત છે, ડેટાબેઝમાં લાગુ કરવામાં આવે છે, અને ફક્ત-ઉમેરી શકાય તેવા ઑડિટ લૉગમાં નોંધવામાં આવે છે.
એક જ લૉગિન શેર કરવું એ એકાઉન્ટ એક્સેસમાં ગરબડ થવાનું કારણ બને છે. Zinn Digital® પર દરેક વ્યક્તિની પોતાની આગવી ઓળખ હોય છે, અને એક્સેસ એ સદસ્યતા છે — એક વપરાશકર્તા, એક સંસ્થા અને એક ભૂમિકા — જેને તમે સ્વતંત્ર રીતે આપી શકો છો, બદલી શકો છો અથવા રદ કરી શકો છો.
દરેક સહયોગી અમારા આઇડેન્ટિટી લેયર Keycloak દ્વારા પોતાની ઓળખ સાથે સાઇન ઇન કરે છે. કોઈ તમારો પાસવર્ડ ટાઈપ કરતું નથી, કોઈ બ્રાઉઝર સેશન શેર કરતું નથી, અને કોઈને દૂર કરવા માટે પાસવર્ડ બદલવાની અને તે અન્ય કોણ જાણતું હતું તે શોધવાની દોડધામ કરવાને બદલે માત્ર એક જ પગલું લેવું પડે છે.
ખાતાઓ વંશવેલો ધરાવે છે — એક પુનર્વિક્રેતા સંસ્થા ગ્રાહક સંસ્થાઓ ધરાવે છે, અને ગ્રાહક સંસ્થાઓ સાઇટ્સ ધરાવે છે. સભ્યપદ કોઈ સંસ્થા અને તેની હેઠળની દરેક વસ્તુ પર લાગુ થાય છે, જેથી તમે તમારા અન્ય ગ્રાહકોને ક્યારેય ખુલ્લા પાડ્યા વિના કોઈ એજન્સી ગ્રાહકને તેમની પોતાની સંસ્થાનું નિયંત્રણ સોંપી શકો છો.
ભાડૂતનું વિભાજન (ટેનન્ટ સેપરેશન) એ એપ્લિકેશન કોડમાં એવું કોઈ ફિલ્ટર નથી જેને કોઈ બગ અવગણી શકે. Postgres રો-લેવલ સિક્યોરિટી દરેક ક્વેરીને કૉલરના સંગઠન સબટ્રી સુધી મર્યાદિત કરે છે, તેથી તમારા કાર્યક્ષેત્રની બહારની કોઈપણ વિનંતી પાસે પરત કરવા માટે કશું હોતું નથી.
તમારા કાર્યક્ષેત્રની બહારની કોઈ સંસ્થા અથવા સાઇટ માટે વિનંતી કરો અને API પરવાનગીની ભૂલને બદલે સામાન્ય 'મળ્યું નથી' (not-found) સાથે જવાબ આપે છે. પરવાનગીની ભૂલ પુષ્ટિ કરશે કે રેકોર્ડ અસ્તિત્વમાં છે; 'મળ્યું નથી' કોઈ બહારની વ્યક્તિને કંઈપણ જણાવતું નથી.
પરવાનગીઓ વિગતવાર કી છે — મોડ્યુલ વત્તા ક્રિયા, જેમ કે sites.restart અથવા billing.refund — અને ભૂમિકાઓ તેમને એકત્રિત કરે છે. ચાર ભૂમિકાઓ વાસ્તવિક ટીમોને જરૂરી એવા માળખાને આવરી લે છે, અને દરેક ભૂમિકા એ ડેટા છે જેને અમે સીડ કરીએ છીએ, કોડમાં છુપાયેલું લોજિક નથી.
સંપૂર્ણ નિયંત્રણ: પેટા-સંસ્થાઓ બનાવો, સભ્યોને આમંત્રિત કરો અને દૂર કરો, ભૂમિકાઓ બદલો, API કી મેનેજ કરો, સાઇટ્સ બનાવો, પુનઃપ્રારંભ કરો, પર્જ કરો, સ્થગિત કરો અને કાઢી નાખો, બિલિંગ અને ઇન્વૉઇસેસ ચલાવો, ટિકિટ ઉઠાવો અને ઑડિટ લૉગ વાંચો. એવી ભૂમિકા જે તમે તમારા માટે રાખો છો.
સંસ્થા, તેના સભ્યો અને પ્લાન કેટલોગ જુએ છે, અને ઇન્વૉઇસેસ, ચુકવણી પદ્ધતિઓ અને શુલ્કનું સંચાલન કરે છે. એક પણ સાઇટ બનાવવા, બદલવા કે કાઢી નાખવાની ઍક્સેસ નથી — એક બાહ્ય એકાઉન્ટન્ટ માટે જે જરૂરી છે તે જ સ્વરૂપ.
સાઇટ્સ જુએ છે અને બનાવે છે, સેવાઓ પુનઃપ્રારંભ કરે છે, કેશ સાફ કરે છે, API કીનું સંચાલન કરે છે અને ટિકિટો પર કામ કરે છે. જાણીજોઈને બાકાત રાખેલ છે: બિલિંગ, ઇનવૉઇસ, ચુકવણી પદ્ધતિઓ, સભ્ય સંચાલન, સાઇટ સસ્પેન્શન અને સાઇટ ડિલીટ કરવી. કોન્ટ્રાક્ટર તમને બિલ આપવા અથવા કોઈપણ વસ્તુનો નાશ કરવા સક્ષમ બન્યા વિના બનાવી શકે છે.
સંસ્થા, તેના સભ્યો, તેની સાઇટ્સ, તેનું બિલિંગ, પ્લાન કૅટેલૉગ, ટિકિટો, અનુવાદની સ્થિતિ અને ઑડિટ લૉગ જુએ છે — અને તેમાંથી કશું પણ બદલી શકતા નથી. જે ક્લાયન્ટ વિઝિબિલિટી ઇચ્છે છે, ઑડિટર અથવા હિસ્સેદાર કે જેમને ફક્ત જોવાની જરૂર છે તેમના માટે યોગ્ય મંજૂરી.
ઍક્સેસ સોંપવી ત્યારે જ સલામત છે જ્યારે તમે જેને ઍક્સેસ સોંપો છો તે એકાઉન્ટ્સ પર કબજો મેળવવો મુશ્કેલ હોય. એકાઉન્ટ પરની દરેક વ્યક્તિ માટે, દરેક પ્લેટફોર્મ પર Keycloak દ્વારા પ્રમાણીકરણ ચાલે છે.
સપોર્ટ કાર્યમાં કેટલીકવાર તમારા એકાઉન્ટની અંદર જોવાનો સમાવેશ થાય છે. તે ઍક્સેસ અન્ય તમામ બાબતોની જેમ સમાન પરવાનગી મોડેલ દ્વારા સંચાલિત થાય છે — સ્ટાફ ફક્ત સ્ટાફ સંસ્થામાં હોય છે, જે મર્યાદિત મંજૂરીઓ ધરાવતા વિભાગોમાં સંગઠિત હોય છે.
કર્મચારીઓને સપોર્ટ, બિલિંગ અને ફાઇનાન્સ, દુરુપયોગ અને વિશ્વાસ-અને-સુરક્ષા, વેચાણ, ઓનબોર્ડિંગ, એન્જિનિયરિંગ અને ઓપ્સ, માર્કેટિંગ અને મેનેજમેન્ટમાં જૂથબદ્ધ કરવામાં આવ્યા છે. દરેક ભૂમિકા ચોક્કસ મોડ્યુલ્સ અને ક્રિયાઓ પ્રદાન કરે છે, જેથી એજન્ટ એડમિન કન્સોલનો માત્ર તે જ ભાગ જુએ છે જે તેમના કામ માટે જરૂરી હોય અને બાકીનો નહીં.
સપોર્ટ એજન્ટની ભૂમિકા બરાબર આ પરવાનગી આપે છે: ગ્રાહકોને જોવા, ટિકિટો જોવા અને તેનો જવાબ આપવો, સાઇટ્સ જોવી, સાઇટ પુનઃપ્રારંભ કરવી અને તેની કેશ સાફ કરવી. તેમાં કોઈ બિલિંગ કન્ફિગરેશન, કોઈ રિફંડ, કોઈ પ્લાન એડિટિંગ અને કોઈ ફ્લીટ મેનેજમેન્ટ સામેલ નથી. એજન્ટ દ્વારા કરવામાં આવતા સુધારાત્મક પગલાં ભૂમિકા દ્વારા મર્યાદિત છે, સારા ઇરાદાઓ દ્વારા નહીં.
customer.impersonate પરવાનગી Manager ભૂમિકાનો ભાગ નથી — તે ફક્ત Super Admin પાસે જ હોય છે. જ્યારે તમારા વતી કોઈ સત્ર ચાલી રહ્યું હોય, ત્યારે ડેશબોર્ડ પર એક સ્થાયી ઇમ્પર્સનેશન બૅનર દર્શાવવામાં આવે છે જેથી કોણ કાર્ય કરી રહ્યું છે તે અંગે ક્યારેય કોઈ અસ્પષ્ટતા ન રહે.
દરેક વિશેષાધિકૃત અને વહીવટી ક્રિયા ફક્ત-ઉમેરી શકાય તેવા ઑડિટ લૉગમાં ઉમેરવામાં આવે છે જે કર્તા, ક્રિયા, લક્ષ્ય, સહાયક મેટાડેટા, IP સરનામું અને ટાઇમસ્ટેમ્પ રેકોર્ડ કરે છે — ઉત્પાદનમાં સમય-વિભાજિત. માલિકો અને ફક્ત-વાંચી શકે તેવા સભ્યો તેમની સંસ્થાનો લૉગ જાતે વાંચી શકે છે.
સ્ટાફની સંવેદનશીલ અને વિનાશક ક્રિયાઓ ચલાવવામાં આવે તે પહેલાં તેમને ઉચ્ચ-સ્તરના પ્રમાણીકરણ અથવા બે-વ્યક્તિની મંજૂરીની જરૂર પડી શકે છે, અને નવા વિભાગો તથા ભૂમિકાઓ કોડ ફેરફારને બદલે માત્ર રૂપરેખાંકન છે.
સ્ક્રિપ્ટ્સ, CI પાઇપલાઇન્સ, CLI, Terraform પ્રદાતા અને AI એજન્ટો બધા લોકોની જેમ જ સમાન પરવાનગી મોડેલ દ્વારા પ્રમાણિત થાય છે — કોઈ શેર કરેલ માનવીય ઓળખપત્રો નથી, બિલ્ડમાં પેસ્ટ કરેલા કોઈ લાંબા સમય સુધી ચાલતા રહસ્યો નથી.
કીઓ સંસ્થાની માલિકીની હોય છે અને તે સમાન RBAC પરવાનગીઓ સાથે જોડાયેલા વિગતવાર સ્કોપ્સ ધરાવે છે — ફક્ત વાંચવા માટે, બિલિંગ, જોગવાઈ. સભ્યના સમગ્ર એકાઉન્ટને બદલે પાઇપલાઇનને જરૂરી મર્યાદિત સ્કોપ આપો.
ટેસ્ટ-મોડ અને લાઈવ-મોડ કી અલગ હોય છે, જેથી વિકાસ હેઠળનું એકીકરણ આકસ્મિક રીતે અથવા કૉપિ કરેલા એન્વાયર્નમેન્ટ વેરિયેબલ દ્વારા પ્રોડક્શન ડેટા સુધી પહોંચી શકતું નથી.
અમે સિક્રેટનો SHA-256 હેશ અને લુકઅપ પ્રીફિક્સ સ્ટોર કરીએ છીએ — ક્યારેય કાચી કી સ્ટોર કરતા નથી. કી બનાવતી વખતે તમે તેને ફક્ત એક જ વાર જોઈ શકો છો. દરેક કી છેલ્લે ક્યારે વાપરવામાં આવી હતી તે ટ્રૅક કરે છે અને અન્ય કોઈપણ બાબતને અસર કર્યા વિના તેને અલગથી રદ કરી શકાય છે.
અમારું MCP સર્વર કોઈપણ MCP-સક્ષમ એજન્ટને કુદરતી ભાષામાં તમારા હોસ્ટિંગનું સંચાલન કરવાની મંજૂરી આપે છે, જે OAuth 2.1 સાથે પ્રમાણિત છે અને તમારી સંસ્થા તથા RBAC ભૂમિકા સુધી મર્યાદિત છે, જેમાં ટૂલ-દીઠ રદ કરી શકાય તેવા ટોકન્સ, વિનાશક ક્રિયાઓ પર પુષ્ટિકરણ, ખર્ચ મર્યાદાઓ અને સંપૂર્ણ ઑડિટ લૉગિંગ શામેલ છે.
એકાઉન્ટ એક્સેસ અને સર્વર એક્સેસ એ અલગ બાબતો છે. સાઇટ-લેવલના ક્રેડેન્શિયલ્સ ડેશબોર્ડમાં સંચાલિત થાય છે, ઓછામાં ઓછા વિશેષાધિકાર સાથે આપવામાં આવે છે અને જેલ કરવામાં આવે છે જેથી એક સહયોગીની શેલ માત્ર એક સાઇટની શેલ રહે.
એક સોલો ઓપરેટર એક જ સંસ્થા અને એક ઓનર મેમ્બરશિપ રાખે છે, અને જ્યારે કોઈ પ્રોજેક્ટ માટે કોન્ટ્રાક્ટર આવે ત્યારે ડેવલપર રોલ ઉમેરે છે. જ્યારે પ્રોજેક્ટ સમાપ્ત થાય છે, ત્યારે મેમ્બરશિપ દૂર કરવામાં આવે છે અને તેમનું સાઇન-ઇન તરત જ કામ કરવાનું બંધ કરી દે છે — રોટેટ કરવા માટે કોઈ શેર કરેલા ઓળખપત્રો બાકી રહેતા નથી.
એક એજન્સી સંસ્થા ટ્રી (organisation tree) નો ઉપયોગ કરે છે. પ્રત્યેક ક્લાયન્ટને તેની પોતાની ચાઇલ્ડ સંસ્થા મળે છે, જેમાં તે ક્લાયન્ટની સાઇટ્સ હોય છે, અને ક્લાયન્ટના પોતાના લોકોને ત્યાં સભ્યપદ મળે છે — જે હિસ્સેદાર માત્ર વિગતો જોવા માંગે છે તેના માટે રીડ-ઓન્લી (read-only), અને જે ક્લાયન્ટ જાતે સંચાલન કરવા માંગે છે તેના માટે માલિક (owner). તમારા કર્મચારીઓ ટ્રીમાં ઉચ્ચ સ્તરે સભ્યપદ ધરાવે છે અને સમગ્ર પોર્ટફોલિયો જુએ છે; ક્લાયન્ટ માત્ર તેમની પોતાની શાખા જુએ છે, અને Row-Level Security જ એ બાબત છે જે તેને માત્ર વચન રાખવાને બદલે વાસ્તવિક બનાવે છે.
રિસિલર પણ એ જ રીતે કાર્ય કરે છે, એક સ્તર વધુ ઉપર: રિસિલર સંસ્થા ગ્રાહક સંસ્થાઓ ધરાવે છે, પ્રત્યેકના પોતાના સભ્યો, બિલિંગ વ્યૂ અને સાઇટ્સ હોય છે. આ જ પ્રાથમિક તત્વ પેટા-ખાતાઓ, એજન્સી ટીમો અને રિસેલર શ્રેણીઓને સંચાલિત કરે છે — તેમાંથી કોઈપણ માટે કોઈ અલગ, નબળી પદ્ધતિ નથી.
કાર્ડ વગરના 14 દિવસના ટ્રાયલ પર બધું જ ઉપલબ્ધ છે. ચુકવણીની વિગતો વિના સાઇન અપ કરો, કોઈ સહકર્મીને આમંત્રિત કરો, દરેક ભૂમિકા શું ઍક્સેસ કરી શકે છે અને શું નહીં તે જુઓ, અને તમારો પોતાનો ઑડિટ લૉગ પાછો વાંચો.
આજે સભ્યપદ તેની ભૂમિકા સમગ્ર સંસ્થા અને તે વંશવેલામાં તેની નીચેની તમામ બાબતોમાં પ્રદાન કરે છે, તેથી સાઇટ સેટ્સને અલગ કરવાનો માર્ગ સંસ્થાઓને અલગ કરવાનો છે — તે સાઇટ્સને તેમની પોતાની પેટા સંસ્થામાં મૂકો અને ત્યાં સભ્યપદ પ્રદાન કરો. તે એજન્સીઓ અને રિસેલર્સ માટે એક સ્પષ્ટ મૉડેલ છે, જ્યાં દરેક ગ્રાહક પહેલેથી જ પોતાની મર્યાદા ઇચ્છે છે. પ્રતિ-સભ્યપદ સંસાધન મર્યાદા નિર્ધારિત કરવી, એટલે કે એક સંસ્થામાં એક સિંગલ સભ્યપદને નિર્દિષ્ટ સાઇટ્સ સાથે જોડવું, એ એક આયોજિત સુધારો છે, નહીં કે હાલમાં ઉપલબ્ધ સુવિધા.
Developer ભૂમિકા સાઇટ ડિલીટ અથવા સાઇટ સસ્પેન્શન ધરાવતી નથી — તે કી Owner ભૂમિકાની છે. તે સાઇટ્સ જોવાની અને બનાવવાની, સેવાઓ પુનઃપ્રારંભ કરવાની, કૅશ સાફ કરવાની, API કી મેનેજ કરવાની અને ટિકિટો પર કામ કરવાની મંજૂરી આપે છે. ડિપ્લોયમેન્ટ અને push-to-live પરવાનગીઓ પણ Developer ગ્રાન્ટનો ભાગ નથી, તેથી પ્રોડક્શનમાં પ્રમોશન એકાઉન્ટ માલિક પાસે રહે છે. તેને સ્ટેજિંગ સાથે જોડો જેથી બિલ્ડ કાર્ય શરૂઆતથી જ લાઇવ સાઇટની બહાર થાય.
તે સંપૂર્ણપણે સ્ટાફની ભૂમિકા પર આધાર રાખે છે, અને દરેક ભૂમિકા પરવાનગી કીઓનો એક મર્યાદિત સેટ છે. સપોર્ટ એજન્ટ, ઉદાહરણ તરીકે, તમારું એકાઉન્ટ અને સાઇટ્સ જોઈ શકે છે, તમારી ટિકિટો જોઈ અને તેનો જવાબ આપી શકે છે, સાઇટને પુનઃપ્રારંભ કરી શકે છે અને તેનો કેશ સાફ કરી શકે છે — અને બિલિંગ રૂપરેખાંકન, રિફંડ, પ્લાન અથવા ફ્લીટને સ્પર્શ કરી શકતા નથી. ગ્રાહક તરીકે સાઇન ઇન કરવું એ એક અલગ પરવાનગી છે જે ફક્ત Super Admin પાસે હોય છે, અને જ્યારે આવું થાય છે ત્યારે ડેશબોર્ડ સતત પ્રતિરૂપિત બેનર પ્રદર્શિત કરે છે. દરેક વિશેષાધિકૃત ક્રિયા ઑડિટ લૉગમાં કર્તા, ક્રિયા, લક્ષ્ય, IP અને ટાઇમસ્ટેમ્પ સાથે નોંધવામાં આવે છે, અને તમે તમારી સંસ્થાના લૉગને જાતે વાંચી શકો છો.
સભ્યપદ દૂર કરો અને તે સંસ્થામાં તેમની ઍક્સેસ સમાપ્ત થઈ જશે — તેમની પાસે હજી પણ તેમની પોતાની ઓળખ છે, પરંતુ તમારા ખાતામાં કોઈ ભૂમિકા નથી અને તેથી કોઈ પરવાનગીઓ નથી. API કી વ્યક્તિગત રીતે રદ કરવામાં આવે છે, જેથી અન્ય કંઈપણ ખલેલ પહોંચાડ્યા વિના pipeline કી કાપી શકાય છે. જો તમે SAML single sign-on નો ઉપયોગ કરો છો, તો તમારા ઓળખ પ્રદાતામાં deprovisioning સાઇન-ઇનને કેન્દ્રીય રીતે હેન્ડલ કરે છે. SSH કી જેવા સાઇટ-લેવલના ઓળખપત્રો ડેશબોર્ડમાં રદ કરવામાં આવે છે, અને દૂર કરવાની પ્રક્રિયા પોતે ઑડિટ-લૉગ કરવામાં આવે છે.
ના — પરંતુ શા માટે તે ચોક્કસપણે જણાવવું યોગ્ય છે. API કી સંસ્થાની માલિકીની છે, કોઈ વ્યક્તિગત સભ્યની નથી, અને તે સમાન પરવાનગી કૅટેલોગ સાથે જોડાયેલ તેના પોતાના ચોક્કસ સ્કોપ ધરાવે છે. તેથી કોઈ વ્યક્તિને કી આપવાને બદલે, તમે તે કામ માટે જરૂરી હોય તેટલા જ મર્યાદિત સ્કોપ સાથે એક કી બનાવો છો, અને કામ પૂર્ણ થતાં તે કી રદ કરો છો. સિક્રેટનો માત્ર હૅશ (hash) જ સંગ્રહિત કરવામાં આવે છે, અને દરેક કી છેલ્લે ક્યારે ઉપયોગમાં લેવાઈ હતી તે રેકોર્ડ કરે છે જેથી ન વપરાયેલી કી સરળતાથી શોધી શકાય અને તેને નિવૃત્ત કરી શકાય.
હા. અમારું MCP સર્વર OAuth 2.1 વડે એજન્ટ્સને પ્રમાણિત કરે છે અને તેમને તમારી સંસ્થા તેમજ તમારી RBAC ભૂમિકા સુધી મર્યાદિત કરે છે, જેમાં ટૂલ-દીઠ રદ કરી શકાય તેવા ટોકન્સ હોય છે, જેથી તમે સામાન્ય ઍક્સેસ આપવાને બદલે ચોક્કસ ક્ષમતા પ્રદાન કરો છો. વિનાશક ક્રિયાઓ માટે પુષ્ટિકરણ જરૂરી છે, ખર્ચ મર્યાદાઓ લાગુ પડે છે, અને દરેક ક્રિયા માનવીય પ્રવૃત્તિની જેમ સમાન ઑડિટ લૉગમાં નોંધાય છે.
Postgres રો-લેવલ સિક્યોરિટી ક્વેરીઝને ડેટાબેઝમાં જ કૉલરની સંસ્થાના સબટ્રી સુધી સીમિત રાખે છે, જેમાં એપ્લિકેશન-લેવલ ફિલ્ટર એકમાત્ર લાઇન હોવાને બદલે ઊંડાણપૂર્વકનું રક્ષણ આપે છે. કાર્યક્ષેત્રની બહારના રેકોર્ડ્સ માટેની વિનંતીઓ પરવાનગીની ભૂલને બદલે નોટ-ફાઉન્ડ આપે છે, જેથી શું અસ્તિત્વમાં છે તે વિશે કશું જાહેર ન થાય. સર્વર બાજુએ, CageFS દ્વારા દરેક-સાઇટનું અલગતાકરણ દરેક ટેનન્ટના શેલ અને ફાઇલોને તેમની પોતાની સાઇટ સુધી જ સીમિત રાખે છે.
હા. 14 દિવસની ટ્રાયલ કાર્ડ-મુક્ત છે — કોઈ ચુકવણી વિગતો નહીં, કોઈ પ્રતિબદ્ધતા નહીં — અને પાંચ સાઇટ્સ સુધી Footprint-Free હોસ્ટિંગ આવરી લે છે. તમે પ્રતિબદ્ધ થાઓ તે પહેલાં કોઈ સહકર્મીને આમંત્રિત કરવા, ભૂમિકા સોંપવા અને સરહદો તમારી જરૂરિયાત મુજબ વર્તે છે તેની ખાતરી કરવા માટે આટલું પૂરતું છે.
કાર્ડ વિનાના 14-દિવસીય ટ્રાયલ સાથે પ્રારંભ કરો, કોઈને આમંત્રિત કરો, અને પરવાનગી મૉડલને તેનું કાર્ય કરતા જુઓ — તમે નામ આપી શકો તેવી ભૂમિકાઓ, તમે રદ કરી શકો તેવા સ્કોપ્સ, અને એક ઑડિટ લૉગ જે ચોક્કસપણે જણાવે છે કે કોણે શું કર્યું.
મફતમાં શરૂ કરો