پنل مدیریت برای کاربر انسانی طراحی شده است. اما در عمل، بسیاری از کارهای مالی باید بهصورت خودکار و از داخل سامانههای دیگر انجام شود.
مثلاً بعد از تأیید واریز بانکی، ERP باید کیف پول را شارژ کند. سامانهٔ شریک باید گزارش دهد که یک خدمت واقعی تحویل شده است. یا یک فرایند داخلی باید همان مستنداتی را که کارشناس بارگذاری میکند، برای ثبت اختلاف ارسال کند.
این کارها را نمیتوان با دادن کوکی نشست اپراتور یا باز کردن دسترسی مستقیم به لایهٔ کنترل خوشه حل کرد. کلاینت یکپارچهسازی در فینو برای همین ساخته شده است: یک اعتبارنامهٔ ماشینی که به همان مسیرهای پنل دسترسی دارد، اما با قواعد امنیتی مناسب سامانههای بیرونی.
API جداگانه نیست؛ همان امکانات، مسیر احراز هویت متفاوت
کلاینت یکپارچهسازی محصول موازی نیست. فقط راه دومی برای احراز هویت است.
وقتی درخواست معتبر باشد، همان سطح دسترسی و همان ادعاهای نشست ساخته میشود که در ورود از مرورگر ساخته میشود. در نتیجه، همهٔ مسیرهای موجود بدون تغییر کار میکنند و قاعدهٔ مجوزدهی هم یکی میماند. پنل و رابط برنامهنویسی دربارهٔ «چه کسی چه کاری مجاز است» دو روایت متفاوت نمیسازند.
این موضوع وقتی پول جابهجا میشود حیاتی است. اگر API ماشینی از منطق پنل جدا بیفتد، برای یک کیف پول دو منبع حقیقت درست میشود.
چرا امضای درخواست، نه توکن ساده
این کلاینتها عملیات مالی انجام میدهند. توکنی که فقط یکبار دیده شود و بعداً دوباره قابل استفاده باشد، برای چنین مسیری کافی نیست.
فینو برای هر درخواست، امضای HMAC روی روش HTTP، مسیر کامل همراه با پارامترها، هش بدنه و زمان میخواهد:
X-Finno-Key-Id— شناسهٔ اعتبارنامهX-Finno-Timestamp— زمان درخواست؛ باید حداکثر حدود پنج دقیقه با ساعت سرور فاصله داشته باشدX-Finno-Signature— امضای نسخهٔ یک بهصورت هگزادسیمال
امضای ربودهشده فقط برای همان محتوا معتبر است. نمیتوان آن را برای مبلغ دیگر، مصرفکنندهٔ دیگر یا مسیر دیگر استفاده کرد. این همان نکتهای است که در بسیاری از امضاهای فقط روی بدنه وجود ندارد؛ و تفاوت میان یک GET شنودشده و یک POST جعلی را مشخص میکند.
اگر شناسه ناشناس باشد، کلاینت غیرفعال باشد، امضا نادرست باشد، یا آدرس مبدأ خارج از محدودهٔ مجاز باشد، پاسخ رد یکسان برمیگردد. مهاجم از تفاوت پیامها چیزی دربارهٔ صحت کلید نمیفهمد.
محدودهٔ دسترسی: پیشفرض ممنوع
محدودهٔ دسترسی از مسیر درخواست بهصورت <منبع>:<خواندن|نوشتن> استخراج میشود و عمداً درشتدانه نگه داشته شده است. اگر برای هر مسیر قاعدهٔ جدا تعریف شود، با اضافه شدن مسیرهای جدید کهنه میشود؛ و جدول مجوزی که کهنه شده باشد، معمولاً بهسمت باز بودن خطا میرود.
منبع جدیدی که زیر /v1/ اضافه شود، تا وقتی صریحاً اعطا نشده باشد در دسترس نیست. کلاینت بدون محدوده به هیچ مسیری نمیرسد. دسترسی نوشتن روی یک منبع، خواندن همان منبع را هم شامل میشود. هیچ کلاینتی نمیتواند اعتبارنامهٔ دیگری بسازد یا دسترسی خود را گسترش دهد؛ مدیریت کلاینتها جزو محدودههای قابل اعطا نیست.
دامنهٔ مصرفکنندگان جدا از محدودهٔ دسترسی تعریف میشود:
- granted (پیشفرض): فقط مصرفکنندگانی که صریحاً به این کلاینت متصل شدهاند
- all: همهٔ مصرفکنندگان؛ فقط برای موارد خاص و کنترلشده
اگر دامنه مشخص نباشد، دسترسی داده نمیشود. در کار با پول دیگران، فرض بر محدود بودن است نه باز بودن.
دو سطح و دو نوع احراز هویت
| سطح | پورت | کاربرد | احراز هویت |
|---|---|---|---|
| API داشبورد | :9090 | مدیریت، واریز، فاکتور، تعدیل، اختلاف، گزارش | درخواست امضاشده با HMAC |
| درگاه | :8080 | ترافیک اندازهگیریشده، از جمله سرویس مجازی | اعتبارنامهٔ معمول مصرفکننده + در صورت نیاز تأیید امضای Ed25519 |
یک کلاینت میتواند هر دو را داشته باشد: رمز HMAC برای داشبورد و کلید عمومی برای تأیید درخواستهای درگاه.
سرویس مجازی: صورتحساب برای خدمتی که بیرون فینو رخ میدهد
بعضی خدمات مثل فراخوانی API قیمتگذاری میشوند، اما خود خدمت بیرون فینو انجام میشود؛ مثلاً مشاوره، بازدید میدانی، یا بستن تیکت در سامانهای دیگر.
با سرویس مجازی، سامانهٔ بیرونی میتواند تعداد واحد مصرف را روی مسیر اصلی درگاه اعلام کند. فینو همانند ترافیک معمولی، رزرو، نهاییسازی و ثبت حسابداری را انجام میدهد. پول واقعی و رد دفتر واقعی ثبت میشود؛ فقط لولهٔ تحویل خدمت، فینو نیست.
به همین دلیل بعداً اختلاف اهمیت پیدا میکند: وقتی خود «گزارش تحویل» محل اختلاف باشد نه فقط محاسبه، به فرایند تطبیق نیاز دارید نه به فایل اکسل پراکنده.
چه امکاناتی باز میشود
- شارژ کیف پول و پرداخت فاکتور از ERP یا CRM بدون دخالت دستی در هر مرحله
- دسترسی سامانهٔ شریک فقط به مصرفکنندگانی که شما مشخص کردهاید
- ثبت تحویل خدمت بیرون از پلتفرم، با همان دقت دفاتر فینو
- استفاده از همان قواعد تأیید دو مرحلهای و اختلاف که اپراتورها میشناسند، اینبار از داخل اتوماسیون
یک سؤال عملی
اگر امروز سامانهای دیگر باید در فینو عملیات مالی انجام دهد، نشست مرورگر یک نفر را در اختیارش میگذارید، یا اعتبارنامهای محدود، امضاشده و قابل ابطال میدهید؟