Thứ 2 là tôi không muốn chứng minh gì cả. Tôi chỉ không hiểu tại sao anh cần 2 bus. webservice anh gửi thông tin tài khoản đi (sau khi được anh mã hóa + SQS mã hóa), rồi sau đó webservice nhận lại thông tin giao dịch về, nghĩa là webservice có tất cả thông tin, vậy thì cần tách thành 2 bus làm gì.
Tài khoản của bank (login credentials) sau khi gửi sang crawler service thì cũng xóa khỏi web service rồi bác, nó chỉ lưu duy nhất account number thôi.
Bệnh nghề nghiệp thôi anh. Tôi làm gì cũng đều hỏi tại sao. Tôi không phải muốn chứng minh chủ thớt thiết kế sai, mà tôi muốn hỏi lí do sâu xa để sau này biết đâu áp dụng được.
Thật ra mình rất thích suy nghĩ kỹ tính này của bác, bản thân mình cũng là người cầu kỳ và khó tính nên trao đổi với bác làm khiến cho mình hào hứng ra phết, mặc dù đôi hơi khó chịu vì chưa rõ nguyên nhân vì sao lại bị vặn vẹo hehe.
Không hiểu tư duy cậu thread lắm, data ngân hàng nằm hết trong cái crawler kia chứ có bảo mật quái gì đâu, data giao dịch nằm hết trong cái web service. Rồi 2 cái bus thằng nào inject vô được cũng soi được thông tin.
Data cậu encrypt hết rồi thì thích thì gửi qua http còn được, cần đếch gì sqs
Hay ý cậu kia là giấu cái crawler service đi thì không ai biết cái database ngân hàng nó nằm ở đâu
. Nếu thế thì lập luôn 1 cái vpc thì thằng nào soiđc
Nói chung cậu này làm mấy thứ liên quan đến tiền bạc mà tư duy bảo mật như lol, không nói thì thôi nói ra có cức mà tôi dám xài, bài toán security đơn giản cậu vẽ lại 1 cách ngây ngô, tôi nghĩ cậu thread nên học 1 khóa security 101 trước rồi hẵng làm
Tôi nhìn tới nhìn lui cái hình là thấy có mùi security by obscurity đâu đây rồi
Xin bác chỉ giáo thêm kinh nghiệm trong việc inject vào sqs? Còn mình không dùng http vì không muốn các services liên lạc trực tiếp với nhau. Lấy ví dụ 1 ông bưu tá, thay vì phải gặp bác trực tiếp để đưa thư thì nhà bác có cái hòm thư trước cửa, ông ấy chỉ việc nhét bưu kiện vào đó xong đi giao tiếp nhà khác, còn việc lấy ra lúc nào là tùy bác thôi. Chứ nếu ông ấy cứ đứng chờ để gặp được bác thì cả ngày chắc chỉ giao được vài bưu kiện mà thôi.
// Bác nói về vấn đề bảo mật của mình như l*l, nhưng lại không chỉ ra được điểm yếu và khe hở của nó thì ai cũng nói được bác ạ!
At-least-once là vì sau khi message được xử lý thành công sẽ bị xóa khỏi queue nên trong trường hợp có lỗi xử lý hoặc không xóa được thì có thể bị duplicate.
Và khi một message được pull về bởi 1 consumer/receiver thì các consumer khác sẽ không thấy được message này nữa cho đến khi timeout. https://docs.aws.amazon.com/AWSSimp...s.html#standard-queues-at-least-once-delivery
Khách hàng cá nhân thì lượng giao dịch tương đối ít, không khó kiểm soát mà phải dùng hệ thống này.
Doanh nghiệp thì chỉ một số ít doanh nghiệp đặc thù (có quá nhiều giao dịch chuyển khoản). Chứ hầu hết các cty bán lẻ nhiều đơn thì giờ chỉ đối soát qua COD với bên vận chuyển, chứ hạn chế giao dịch chuyển khoản lắm.
Nói chung là ngày xưa bên mình cũng làm rồi, sau nửa năm làm hệ thống như này thì phát hiện ra là không có tiềm năng kinh doanh. Được cái mày mò cách login vào các ngân hàng cũng hay. Phát hiện ra là các hệ thống của ngân hàng hầu như đều nát như shit hết
Cảm ơn bác đã chia sẻ, công nhận là tệp khách hàng của mình thuộc vào dạng đặc thù, chứ không phải khơi khơi mà đi mời chào mọi người sử dụng, vì nó khá là nhạy cảm và high risk.
Nhu cầu như của bác chủ thớt miêu tả là có thiệt và nhiều luôn chứ không ít đâu nhé Bác tham gia các nhóm MMO, Code tool em thấy nhu cầu API Bank như cơm bữa nhưng họ sẽ thuê full source để về tự setup chứ sẽ không tin dùng dịch vụ bên thứ 3 như của bác.
Nhu cầu là có nhưng thớt là thằng nào đâu ai biết, nên chắc chẳng ai dại mà dám dùng service của thớt.
Ai thực sự có nhu cầu tích hợp kiểu này, chắc cũng có khả năng tự setup dc. Thớt build dạng sdk bán source + dịch vụ support, triển khai nghe bộ còn có lý hơn.
thay vì dựa vào crawl để lấy thông tin giao dịch từ bank, có thể lấy từ sms (smart banking dc ko nhỉ?) Mình ko rõ, chỉ nghĩ vậy thôi. Mấy bên nhà mạng hình như có Api cho sms.
tần suất crawl 30 phút theo mình là hơi lâu. 5,10 phút là hợp lý. Cơ mà do thớt tự crawl nên cũng chưa biết mai mốt ngân hàng nó chặn thì thớt giải quyết như nào
Đúng thật trở ngại của mình là chả ai biết mình là ai cả, rất khó để người ta tin tưởng mà sử dụng app.
Trước đây mình có bán sdk và support đấy bác, nhưng hiện tại mình không bán thêm cho khách mới nữa vì đi maintaince cho từng hệ thống rất mệt mỏi và tốn thời gian. Đó là lý do mình đẩy lên cloud, và hiện tại thì mình đang chuyển dần nhóm khách hàng đó sang dung app rồi.
Không hiểu "chấm" này của bác lắm.
Như mình đã trả lời 1 bác ở trên, 30' là tần suất của gói free, trả phí thì chỉ 15' và dĩ nhiên mình có thể hạ thấp hơn vì 1 lượt crawl chỉ tốn vài giây.
Nhu cầu như của bác chủ thớt miêu tả là có thiệt và nhiều luôn chứ không ít đâu nhé Bác tham gia các nhóm MMO, Code tool em thấy nhu cầu API Bank như cơm bữa nhưng họ sẽ thuê full source để về tự setup chứ sẽ không tin dùng dịch vụ bên thứ 3 như của bác.
Yes yes yes, cuối cùng cũng có người nhìn ra 1 phần trong tệp khách hàng của mình rồi. Trước mình có bán sdk đấy bác, nhưng mình đang chuyển dần sang cloud và lộ trình của mình sắp tới là đưa ra 1 bản self-hosted cho những ai không muốn "đưa" thông tin tài khoản lên app của mình.
ý tôi là khi dùng smart banking khi có giao dịch thì bank sẽ bắn sms thông báo về điện thoại.
thay vì yêu cầu id, pass để crawl giao dịch thì có thể dùng sms để track được ko? (Hình như các nhà mạng có public Api cho sms thì phải? tôi không chắc lắm)
ý tôi là khi dùng smart banking khi có giao dịch thì bank sẽ bắn sms thông báo về điện thoại.
thay vì yêu cầu id, pass để crawl giao dịch thì có thể dùng sms để track được ko? (Hình như các nhà mạng có public Api cho sms thì phải? tôi không chắc lắm)
Sms track được chứ với không cần api nhà mạng, 1 thiết bị ngoại vi cắm được cái SIM là được rồi. Nhưng làm vậy thì khác gì tự setup, vì làm xong cái này thì 80% rồi còn lại formart tin nhắn đẩy database rồi dùng BI thống kê thôi . Vậy thì đâu cần cái cloud của anh kia nữa
Sms track được chứ với không cần api nhà mạng, 1 thiết bị ngoại vi cắm được cái SIM là được rồi. Nhưng làm vậy thì khác gì tự setup, vì làm xong cái này thì 80% rồi còn lại formart tin nhắn đẩy database rồi dùng BI thống kê thôi . Vậy thì đâu cần cái cloud của anh kia nữa
Đúng rồi, sms trước mình cũng có tính đến rồi, tuy nhiên nó hay bị trễ, nhiều khi giao dịch cả ngày trời rồi mới báo, thêm vào đó thì sms bị giới hạn ký tự nên sẽ có lúc không hiển thị hết nội dung ghi chú của giao dịch.
Yes yes yes, cuối cùng cũng có người nhìn ra 1 phần trong tệp khách hàng của mình rồi. Trước mình có bán sdk đấy bác, nhưng mình đang chuyển dần sang cloud và lộ trình của mình sắp tới là đưa ra 1 bản self-hosted cho những ai không muốn "đưa" thông tin tài khoản lên app của mình.
Mình cũng từng code cái này cho đội MMO đây.
May mắn cho bạn là đội đó toàn mù công nghệ + tin tưởng nhau.
Nhưng nói thật là ngoài cái tập khách hàng đó ra thì méo thằng nào nó dùng khi bác ném lên cloud đâu.
Vẫn chưa hiểu lắm về việc bác đem lên voz này hỏi. Bác muốn đưa sản phẩm này ra cho tập người dùng lớn hơn hay muốn gì?
Hi mọi người, vừa rồi mình có xây dựng một cái SaaS app nho nhỏ, và có đăng tải lên một vài cộng đồng startup như indiehackers, hacker news... để xin nhận xét. Tuy nhiên thì ứng dụng của mình sử dụng UI là tiếng Việt nên cũng chưa nhận được nhiều quan tâm cũng như đóng góp ý kiến cho lắm. Mà hiện tại ở Việt Nam mình thì lại chưa có website cộng đồng nào về startup cả, nên thôi mạo muội đăng lên đây, vì dù gì voz là nơi mình tham gia đã lâu, lại có không ít cao nhân ẩn dật, hy vọng sẽ nhận được ít nhiều gạch, đá, cát, sỏi, xi măng về hoàn thiện cái dự án biệt phủ của mình.
Để tránh wall of text mình sẽ để nội dung câu chuyện trong spoiler, đại loại là mời anh em ghé thăm trải nghiệm app của mình tại https://transmoni.vn và nếu được cho mình xin chút ý kiến nhận xét, góp ý. Cảm ơn anh em đã bớt chút thời gian ghé qua thớt này, nếu có sai sót mong mod thương tình nhẹ tay đao, xin đa tạ!
Chả là năm vừa rồi covid nó tung hoành ác quá, lúc đầu cũng nghĩ đâu nó đơn giản, hết đợt một tưởng rằng mọi thứ sẽ bình yên trở lại. Ai ngờ đâu, lại ra tiếp tục đợt 2 rồi đợt 3, khiến cho thời gian rảnh rỗi của mình nó tăng lên một cách mất kiểm soát. Vì vậy nên mình quyết định làm một cái gì đó để giết thời gian, cũng như đỡ ngứa tay ngứa chân và khỏi "lụt" nghề code dạo của bản thân.
Lên ý tưởng
Trong lúc vắt óc suy nghĩ xem nên làm gì thì tình cờ có một thành viên trong group lập trình mà mình tham gia có hỏi về vấn đề xin API của ngân hàng cũng như có cách nào để tích hợp chuyển khoản vào website của họ không... Thì mình chợt nhớ ra cũng đã từng rơi vào hoàn cảnh i chang xì đúc, đó là làm cách nào để khách hàng chuyển tiền vào tài khoản công ty thì sẽ tự động cộng tiền trong tài khoản của họ trên website. Lúc đó cũng bế tắc lắm vì đời nào ngân hàng họ chịu cấp API cho cá nhân hay các doanh nghiệp cỡ nhỏ lại chả dính dáng gì đến nghiệp vụ của họ! Và giải pháp cuối cùng là mình quyết định làm một cái module tự động truy xuất giao dịch trong tài khoản để áp vào website của công ty. Nhưng nó là câu chuyện của nhiều năm trước rồi, nay vô tình có người nhắc lại nên mình thử hỏi ông anh con bác Google xem có gì đổi mới chưa, một phần vì muốn trao đổi với thanh niên trên group, một phần cũng để cập nhật tin tức nữa... và thật bất ngờ nó... vẫn vậy. Điểm sáng duy nhất là bắt đầu có định nghĩa về open banking, tuy nhiên chỉ có ông OCB là gia nhập hội này, mà cũng rất hạn chế tính năng (chắc do là đơn vị tiên phong nên cũng chưa dám open quá). Thêm vào đó open banking thì mình cũng cần chủ động truy xuất thông tin chứ khó có thể nào phía ngân hàng lại chủ động gửi instant payment notification cho mình cả. Vì vậy mình quyết định lôi cái module mà mình xây dựng trước đây để làm "cái gì đó" đang trăn trở bấy lâu.
Use case
Như đã trình bày ở trên, use case cho dự án này là việc cung cấp một giải pháp để tích hợp hình thức thanh toán tự động thông qua giao dịch chuyển khoản ngân hàng. Ngoài ra thì mình còn mở rộng thêm về các hình thức thông báo giao dịch và biến động số dư thông qua các kênh nhắn tin trực tuyến như Telegram, Slack... phục vụ trong trường hợp bạn muốn chia sẻ thông tin giao dịch cho gia đình hoặc nhóm làm việc của mình nhưng lại không muốn giao tài khoản ngân hàng cho họ.
Triển khai
Ý tưởng là vậy, mặc dù cái module mình làm trước đây vẫn chạy tốt, thỉnh thoảng ngân hàng họ cập nhật hệ thống thì mình chỉ phải mô đi phê lại chút là lại ngon lành. Nhưng để làm SaaS app thì cần nhiều thứ hơn nữa. Nào là website để quản lý user, cách thức liên kết tài khoản ngân hàng, quản lý lịch trình truy xuất dữ liệu, rồi tiếp đến còn thu phí thuê bao ra sao... hầm bà lằng. Nói chung mình mất khoảng 6 tháng để mọi thứ gọi là hòm hòm, và mất thêm 3 tháng để live test, khá oải.
Trong thời gian thử nghiệm hệ thống mình có dùng free tier của Amazon aws và Google cloud, nên mình cũng dự kiến là nếu lên production cũng sẽ dùng của 2 anh này thôi. Tuy nhiên chi phí thì khá là ối giời ơi nó đắt, free tier thì không thể dùng làm production được, đến lúc "on air" thì tiền đâu ra mà trả trong thời gian đầu khi chưa có khách hàng. May mắn thay khi tìm hiểu kinh nghiệm của các startup khác thì thấy họ nhắc đến aws activate, đại loại đây là một chương trình hỗ trợ khởi nghiệp của Amazon, các startup sẽ được tài trợ một số tiền (quy ra credits) để thuê cơ sở hạ tầng của họ (chủ yếu là họ nuôi mình lúc còn non nớt, sau này lớn mạnh mình sẽ nuôi lại họ, đây là hợp tác win-win, mà kể cả mình có không dùng của họ thì cũng chả sao, tây nó thoáng). Thấy cũng ngon, nên cũng liều đăng ký thử, và sau vài vòng ép cung, họ đồng ý cấp cho mình 1000 USD sử dụng cho cơ sở hạ tầng và 350 USD cho hỗ trợ kỹ thuật, toẹt vời ông mặt trời.
Và đến giờ phút này thì "nó" đã thực sự hoàn thiện rồi, mặc dù còn nhiều tính năng mà mình muốn phát triển thêm nữa nhưng những gì trong ý tưởng của mình đã hoàn thành, giờ thì chờ xem thiên hạ đón nhận nó ra sao mà thôi.
Hi cả nhà, sau một ngày đăng đàn mình đã nhận được khá nhiều ý kiến đóng góp của mọi người, thật sự rất cảm ơn các bác đã bớt chút thời gian ghé thăm app của mình. Post này mình sẽ giải thích thêm về một số vấn đề mà các bác đã đặt câu hỏi như sau:
Vấn đề use case
Lấy ví dụ với số lượng giao dịch như trong ảnh mình đính kèm dưới đây, nó quá nhiều các bác ạ. Và với số lượng lớn như vậy sẽ đến lúc các bác cần nhân lực riêng chỉ để phục vụ cho việc đối chiếu giao dịch. Trong trường hợp của mình trước đây thì không chỉ 1, mà đến 3 người để làm việc này. Tuy nhiên sức người có hạn, nhân sự của các bác làm việc tối đa cũng chỉ 8-10 tiếng 1 ngày mà thôi, thêm nữa họ còn nghỉ cuối tuần, nghỉ lễ... còn khách hàng thì không, họ có thể thực hiện giao dịch bất cứ lúc nào họ cần, kể cả nửa đêm. Vậy trong trường hợp không có nhân lực đối chiếu giao dịch, khách hàng sẽ phải chờ đến giờ làm việc, cuối tuần hoặc nghỉ lễ thì phải chờ đến ngày làm việc tiếp theo => mất khách. View attachment 374010
Thật sự mà nói thì mình làm app này không phải theo kiểu cọc đi tìm trâu, mà nhu cầu là hiện hữu, vì trong mô hình kinh doanh chính mà mình đang vận hành nó có những vấn đề phát sinh cần đến giải pháp này. Nghĩa là nhu cầu có rồi, mình chỉ là người cung cấp giải pháp mà thôi.
Vấn đề bảo mật
Mình sẽ giải thích thêm về việc bảo mật thông tin tài khoản của khách hàng bằng hình ảnh dưới đây. View attachment 374011
Chú giải như sau:
Web service: là service sẽ tương tác trực tiếp với người dùng, như đăng ký hay quản lý subscription. Sau khi người dùng liên kết tài khoản, service này sẽ ngay lập tức mã hóa toàn bộ thông tin bằng RSA public key (4096 bits), sau đó gửi lên SQS-A (sử dụng mã hóa AES-256 bits). Web service chỉ có quyền PUB lên SQS-A mà không có quyền SUB để gọi ngược thông tin trên SQS-A về.
Crawler service: là service tương tác với phía ngân hàng, nó có quyền SUB vào SQS-A để nhận thông tin tài khoản web service gửi lên, và sử dụng RSA private key để giải mã thông tin đó (web service không có private key này). Sau khi truy xuất thông tin giao dịch nó sẽ gửi thông tin theo SQS-B, nơi nó có quyền PUB nhưng quyền SUB lại chỉ có ở web service mà thôi.
Bên cạnh đó mỗi service đều có một database riêng đã thiết lập chỉ được cấp quyền truy cập từ chính service mà nó phụ thuộc. Các services này hoàn toàn không có bất kỳ liên hệ nào với nhau, hay nói cách khác là không dựa vào nhau để vận hành. Chính vì vậy kể cả trong trường hợp xấu nhất, web service của mình có bị tấn công, thì cũng không thể mò được ra crawler service của mình ở đâu cả.
Lưu thông tin tài khoản bank, ông thớt nghĩ đơn giản nhưng làm không kĩ là vỡ mồm đấy. Nếu chơi được với bank thì điều kiện cần là phải theo chuẩn thế giới, điều kiện đủ là mang lại lợi ích TO LỚN cho bank. Nếu ông nghĩ có thể theo được business này và làm 1 cách hoàn chỉnh (kiếm VC support chẳng hạn...) thì hẵng tiếp tục, còn không thì nên nghỉ sớm cho đỡ mất time.
Khó vậy nên nhiều nơi chủ yếu chơi payment gateway. Nhiều thằng lớn như: Momo, Tiki, Zalopay...theo mình biết thì nó không lưu thông tin tài khoản bank hay CC, mà phải để ở bên thứ 3 với độ uy tín cực kì cao, ví dụ Cybersource của VISA. Ở bên trên ông thớt có nói microservice architecture + Encryption in transit, nghe có vẻ hợp lý, ok về mặt tech, mình tin là nhiều người dư sức design và implemnt, nhưng cái khó nhất ở đây là về business cơ.
Về ý kiến cá nhân thì mình không thấy lợi ích to lớn của app này mang lại, trong khi risk lại quá lớn. Nhiều khi phải xuất thông tin khi thanh toán mình đã khá quan ngại rồi chứ đừng nói tới dùng app để lấy thông tin từ thẻ hay tài khoản. Bài học về leak thông tin thẻ thì quá nhiều rồi, từ thằng bé -> cực kì lớn.
Bác tham gia các nhóm MMO, Code tool em thấy nhu cầu API Bank như cơm bữa nhưng họ sẽ thuê full source để về tự setup chứ sẽ không tin dùng dịch vụ bên thứ 3 như của bác.
