Báo cáo thực tập xây dựng hệ thống phần mềm erp

ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINH TRƯỜNG
ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA HỆ
THỐNG THÔNG TIN

BÁO CÁO THỰC TẬP DOANH NGHIỆP
XÂY DỰNG HỆ THỐNG PHẦN MỀM ERP

Công ty thực tập:
Người phụ trách:
Thực tập sinh:

CÔNG TY CỔ PHẦN TẬP ĐỒN
WATA
Ngơ Vũ Quyền
Trần Thế Anh

TP. Hồ Chí Minh, Tháng 4 năm 2022


LỜI CẢM ƠN
Sau quá trình học tập và rèn luyện tại trường Đại học Công nghệ thông tin để
trau dồi kiến thức và kỹ năng, em đã nhận rất nhiều sự quan tâm, giúp đỡ của q thầy
cơ, gia đình và bạn bè. Với lòng biết ơn sâu sắc nhất, em xin gửi lời cảm ơn đến
trường và quý thầy cô khoa Hệ thống thông tin đã truyền đạt vốn kiến thức làm nền
tảng cho em trong quá trình thực tập.
Trong q trình thực tập tại Cơng Ty Cổ Phần Tập Đoàn WATA, em đã được
trang bị những kỹ năng mềm, nâng cao và hồn thiện kiến thức chun mơn thông qua
các công nghệ mới sử dụng cho lĩnh vực Project Manager cùng việc tiếp xúc dự án
thật mà công ty đã thực hiện.
Em xin chân thành cảm ơn ông Đàm Văn Thiện - Tổng giám đốc Công Ty Cổ Phần
Tập Đồn WATA, anh Ngơ Vũ Quyền – Senior Software Engineering, anh Nguyễn

Thanh Tuấn – Project Manager đã tận tình giúp đỡ em trong quá trình thực tập. Những
kiến thức và kinh nghiệm trong suốt thời gian qua đã giúp em dần hồn thiện và có
thêm kinh nghiệm về phân tích, phát triển phần mềm, hiểu thêm về các kiến trúc và
công nghệ thịnh hành. Tuy nhiên, do kinh nghiệm thực tiễn cịn hạn chế, bài báo cáo
khơng thể tránh những sai sót. Chính vì vậy, em rất mong nhận được những ý kiến
đóng góp của Thầy, Cơ để em hồn thiện bản thân tốt hơn.

Thành phố Hồ Chí Minh, Tháng 4 năm 2022
Sinh viên thực hiện
Trần Thế Anh


NHẬN XÉT CỦA GIẢNG VIÊN
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………

…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………


Mục Lục:

LỜI CẢM ƠN ...............................................................................................................

2

NHẬN XÉT CỦA GIẢNG VIÊN ................................................................................

3

1

2

GIỚI THIỆU CƠNG TY CỔ PHẦN TẬP ĐỒN WATA..............................8
1.1 Thơng tin chung .................................................................................................

8

1.2 Lĩnh vực hoạt động .............................................................................................

8

1.3 Đối tác của cơng ty ............................................................................................

8

Q TRÌNH THỰC TẬP ..............................................................................

9

2.1 Giới thiệu tổng quan dự án và yêu cầu công việc ..............................................

9

2.1.1

Tổng quan các dự án ...............................................................................

9

2.1.2

Bảng chi tiết từng tuần ............................................................................

9

2.2 Kết quả đạt được .............................................................................................. 10
3

CƠ SỞ LÝ THUYẾT.....................................................................................

10

3.1 Kiến thức về xây dựng process management ..................................................

10

3.1.1

Những quy trình quản lý dự án tham khảo
...........................................

10

3.2 Các kiến trúc hệ thống ..................................................................................... 11
3.2.1

Event driven architecture ...................................................................... 11

3.2.2

Microservice

3.2.3

Serverless

3.3 CORS

......................................................................................... 13

.............................................................................................. 15

...............................................................................................................

17

3.3.1

Khái niệm Same origin policy .............................................................. 17

3.3.2

Khái niệm CORS .................................................................................. 18

3.3.3

Client - Side CORS ............................................................................... 18

3.3.4

Server - Side CORS .............................................................................. 20


3.4 Các kiến trúc server .........................................................................................

22

3.4.1 Server là gì ? .........................................................................................

22

3.4.2 Một số kiến trúc server phổ biến .......................................................... 23
3.5 Mơ hình hóa UML ...........................................................................................

27

3.5.1 Khái niệm .............................................................................................. 27

4

3.5.2 Use-case diagram ..................................................................................

27

3.5.3 Tài liệu đặc tả use-case .........................................................................

31

3.5.4 Sơ đồ lớp ...............................................................................................

32

3.5.5 Activity diagram ...................................................................................

33

3.5.6 Sequence diagram .................................................................................

34

3.5.7 State chart diagram ...............................................................................

34

Các công việc, dự án đã tham gia thực hiện và kết quả ............................. 35
4.1 Module HRM trong nền tản ERP .................................................................... 35
4.1.1 Quản lý nhân sự ....................................................................................

35

4.1.2 Quản lý dự án ........................................................................................ 35
4.1.3 Quản lý nguồn lực ở các dự án ............................................................. 35
4.1.4 Thống kê lịch làm việc của nhân viên .................................................. 35
4.1.5 Quản lý lịch nghỉ .................................................................................. 36
4.2 Công cụ sử dụng ..............................................................................................

36

4.2.1 Jira ......................................................................................................... 36
4.2.2 Slack .....................................................................................................

36

4.2.3 Google meet ..........................................................................................

36

4.3 Framework
5

.......................................................................................................

36

ĐÁNH GIÁ NHẬN XÉT ...............................................................................

37

5.1 Kết quả đạt được .............................................................................................. 37

Trần Thế Anh – Software Engineer

5


5.2 Những hạn chế................................................................................................. 37
6

TỔNG KẾT............................................................................... ............................

Trần Thế Anh – Software Engineer

38

6


1 GIỚI THIỆU CƠNG TY CỔ PHẦN TẬP ĐỒN WATA
1.1 Thơng tin chung
Cơng Ty Cổ Phần Tập Đồn WATA là một trong những công ty hàng đầu về Dịch
vụ giải pháp phần mềm có trụ sở tại Thành phố Hồ Chí Minh. Đến với Cơng Ty Cổ Phần
Tập Đồn WATA, khách hàng sẽ có cơ hội làm việc với những thành viên trẻ trung,
năng động, tài năng. Khách hàng/Đối tác của chúng tôi đến từ Bắc Mỹ, Úc, Châu Âu,
Nhật Bản, Singapore và Hàn Quốc. Chúng tôi đang tìm kiếm ứng viên Kỹ Sư Cầu Nối
(BrSE) cho các dự án mới của công ty, người sẽ chịu trách nhiệm thực hiện các công việc
liên quan. Được thành lập vào năm 2016, Cơng Ty Cổ Phần Tập Đồn WATA đã phát
triển nhanh chóng và trở thành cơng ty tiên phong cung cấp các giải pháp phần mềm chất
lượng cao trong nhiều lĩnh vực và phục vụ nhiều khách hàng trong và ngoài nước như
Bắc Mỹ, Singapore, Hàn Quốc và Nhật Bản.
Sứ mệnh của công ty là cung cấp các dịch vụ quản lý và tư vấn đám mây chất lượng
cao với giá cả phải chăng để giúp các công ty khởi nghiệp và cơng ty thuộc mọi quy mơ
hồn thành các dự án ở mọi quy mô. Công ty giúp các doanh nghiệp tận dụng các thế
mạnh của họ và hỗ trợ họ cung cấp các sản phẩm và dịch vụ tuyệt vời để đảm bảo trải
nghiệm tích cực cho người dùng cuối.

1.2 Lĩnh vực hoạt động
− Phát triển và xuất khẩu phần mềm
− Cung cấp giải pháp phần mềm

1.3 Đối tác của cơng ty
Cơng Ty Cổ Phần Tập Đồn WATA là đối tác chiến lược và cung cấp các giải
pháp về công nghệ,…

Trần Thế Anh – Software Engineer

8


2 QUÁ TRÌNH THỰC TẬP
2.1 Giới thiệu tổng quan dự án và yêu cầu công việc
2.1.1 Tổng quan các dự án
Trong quá trình thực tập em đã tham gia vào quá trình được đào tạo với lộ trình bài
bản quy trình on-boarding được cung cấp các kiến thức nền tản phù hợp cho vị trí
Bên cạnh đó, em và team internship được luyện tập qua quá trình phát triển module
HRM trong hệ thống ERP mà cơng ty đang có chiến lược phát triển

2.1.2 Bảng chi tiết từng tuần
Tuần
1

Nội dung công việc
Tìm hiểu về quy trình hoạt động của QA/QC, trách nhiệm và những
nội dung cần trao đổi khi là 1 lập trình viên
Hiểu được quy trình phát triển sản phẩm
Tìm hiểu các tài liệu cần thiết trong quá trình phát triển sản phẩm

2-3

Đi sâu về các loại quy trình phát triển sản phẩm : Waterfall, Agile,
Scrum.
Phân tích phương pháp ước lượng thời gian cho các story và các tasks
Hiểu được các tài liệu UML và cách vẽ được
Luyện tập khả năng làm việc nhóm, trình bày vấn đề
Hiểu được delivery plan và development plan, sự ảnh hưởng của chúng

4-5

Hiểu được phạm vi dự án
Thực hiện WBS và ước lượng cho từng cơng việc
Lên kế hoạch cho q trình phát triển các tính năng
Thống nhất quy trình phát triển sản phẩm
Thống nhất các technical point cần nghiên cứu trước
Chuẩn bị timeline và lên kế hoạch cho sprint tới
Khởi tạo mã nguồn dự án, cài đặt môi trường
Thống nhất quy chuẩn code
Thống nhất quy trình quản lý mã nguồn
Tìm hiểu về các chỉ số đánh giá : burndown, velocity, bug, cost,
workload,…

6-17

Tập trung phát triển hệ thống

Trần Thế Anh – Software Engineer

9


Thực hiện phát triển sản phẩm theo mơ hình Scrum : Daily standup
meeting, Sprint planning, Sprint retrospective , Sprint review
Phân tích requirement và đánh giá story point
Ổn định và cải thiện mã nguồn sau mỗi lần kết thúc sprint
18-22

Tập trung vào giai đoạn UAT
Hiểu được quá trình triển khai sản phẩm, hoàn thiện tài liệu
Hiểu được những cập nhật và đưa ra quyết định bổ sung cập nhật tính
năng trong giai đoạn UAT
Demo sản phẩm cho Project Sponsor, các stake-holder liên quan

23-25

Đánh giá những kĩ năng, kiến thức đã được đào tạo trong thời gian dài
hạn vừa rồi

2.2 Kết quả đạt được
− Nắm được các quy trình phát triển sản phẩm
− Phân tích được 1 sản phẩm
− Nắm được các tài liệu cần thiết ở từng giai đoạn
− Hiểu được các kiến trúc phát triển sản phẩm
− Thành thạo sử dụng các công cụ : Jira, Slack, github,…
− Áp dụng và phát triển sản phẩm bằng các framework : ReactJS, NextJS,
NodeJS, NestJS, TypeORM, clean architecture, CQRS pattern, Ant Design,
Tailwind css,…

3 CƠ SỞ LÝ THUYẾT
3.1 Kiến thức về xây dựng process management
3.1.1 Những quy trình quản lý dự án tham khảo
3.1.1.1 Scrum process

− Scrum: là một quy trình phát triển phần mềm theo phương pháp Agile, vì
thế nó tn thủ các nguyên tắc của Agile. Scrum dựa trên 3 chân lý: Minh

bạch, thanh tra và thích nghi

− Sprint: Quy trình phát triển được thực hiện thông qua các phân đoạn nối tiếp
nhau được gọi là các Sprint. Kết thúc mỗi sprint nhóm phát triển sẽ đưa ra 1
phần tăng trưởng của sản phẩm. Mỗi sprint diễn ra trong vịng khơng q 4

Trần Thế Anh – Software Engineer

10


tuần được diễn ra liên tiếp mà không bị gián đoạn. 1 sprint này bắt đầu
ngay sau khi 1 sprint khác kết thúc.
− Scrum master: là người có hiểu biết sâu sắc về scrum, đảm bảo nhóm làm
việc hiệu quả với scrum. Là người tháo gỡ các thắc mắc cho PO, dev, kiểm
thử.
− Product Owner: chủ sản phẩm: là người chịu trách nhiệm về sự thành công
của dự án. Là người biết rõ về tầm nhìn của sản phẩm. Là người chịu trách
nhiệm quản lý và đảm bảo sự minh bạch của product backlog
− Development team: Một nhóm liên chức năng tự quản lý để tiến hành chuyển
đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ
thống. Đặc điểm của nhóm phát triển là: tự tổ chức và liên chức năng

3.1.1.1.1 Các tạo tác từ Scrum bao gồm
− Product backlog: là nơi lưu trữ các danh sách mong muốn của sản phẩm,
danh sách này được sắp xếp dựa theo độ ưu tiên của từng hạng mục. Độ ưu
tiên cao sẽ được đặt lên đầu danh sách
− Sprint backlog: là bảng cơng việc được nhóm phát triển để quản lý quá
trình sản xuất trong 1 sprint.
3.1.1.1.2 Các hoạt động được thực hiện trong quy trình Scrum là:
− Sprint Planning (Lập kế hoạch Sprint)
− Daily Scrum (Họp Scrum hàng ngày)

− Sprint Review (Rà soát Sprint)
− Sprint Retrospective (Cải tiến Sprint)
− Kết quả: Kết thúc thời gian tìm hiểu, thực tập viên có hiểu biết về quy trình
phát triển Scrum.
− Tạo điều kiện để lên kế hoạch phát triển hệ thống trong kỳ thực tập này

3.2 Các kiến trúc hệ thống
3.2.1 Event driven architecture
3.2.1.1 Định nghĩa

− EDA là một dạng kiến trúc phần mềm được xây dựng trên luồng các event,
sử dụng event như là phương tiện giao tiếp giữa các thành phần hệ thống.

Trần Thế Anh – Software Engineer

11


− Ví dụ : Một module quản lý việc đăng nhập của user cần chứng thực thông tin
của user vừa nhập xong nên tự phát sinh và gửi đi một event gọi là
LoginEvent chứa thông tin user. Event này sau đó được một module có khả
năng thao tác với dữ liệu như WebServer, Database… bắt lấy, thực hiện việc
kiểm chứng và sau đó trả lời kết quả thơng qua LoginResultEvent để module
đăng nhập bắt lấy. Theo cách xử lý này thì module đăng nhập khơng cần biết
module nào và sẽ làm thế nào để thực hiện việc kiểm tra, nó chỉ cần biết gửi
yêu cầu và nhận kết quả sau khi kiểm tra và tất cả những gì nó quan tâm chỉ là
các event được định nghĩa ở mức hệ thống. Hơn nữa, event kết quả trong
trường hợp trên có thể được quan tâm bởi nhiều module khác như module đảm
nhận ghi log và do đó làm cho hệ thống càng mềm dẻo hơn

Trần Thế Anh – Software Engineer

12


3.2.1.2 Vì sao
3.2.1.2.1 Thuận lợi
− Dễ dàng scale up
− Dễ dàng thêm các event type
3.2.1.2.2 Bất lợi
− Kiểm thử sẽ phức tạp nếu các Module liên quan đến nhau nhiều
− Khi 1 module bị fail, phải có các module chứa các file backup
3.2.1.2.3 Khi nào chúng ta sử dụng
− Các hệ thống bất đồng bộ, cần sự phản hồi nhanh
− Các data-block đơn lẻ chỉ tương tác một vài module

3.2.2 Microservice
3.2.2.1 Khái niệm

− Microservice là một kiếu kiến trúc phần mềm. Các module trong phần mềm
này được chia thành các service rất nhỏ (microservice). Mỗi service sẽ được
đặt trên một server riêng

→

dễ dàng để nâng cấp và scale ứng dụng.

3.2.2.2 Phân tích ưu và nhược của Micro-service so với Monolith
3.2.2.2.1 Ưu điểm monolith
− Quá trình phát triển sản phẩm đơn giản, thay đổi code, build và deploy trên

duy nhất 1 project. Không mất nhiều công để set up môi trường.

Trần Thế Anh – Software Engineer

13


− Phát triển trên một ngôn ngữ duy nhất nên chỉ cần nắm sâu và chắc ngơn ngữ

đó là giải quyết được hầu hết vấn đề.
3.2.2.2.2 Nhược điểm monolith
− Theo thời gian, source code phình to ra (requirement change, fix bug, fix
conflig, ...) dẫn đến việc người mới sẽ mất nhiều thời gian để tìm hiểu
− Khơng tận dụng được lợi thế của ngôn ngữ khác, tốn chi phí để thay đổi
nếu dự án quá lớn.
− Deployment sẽ tốn nhiều cost, do source code lớn nên thời gian deploy dài.
− Scale up (Horizontal scale) đơn giản nhưng tốn chi phí cho những phần
không cần scale trong hệ thống
3.2.2.2.3 Ưu điểm micro-service
− Vì chia thành nhiều bài tốn nhỏ nên source code cũng nhỏ hơn, dễ dàng
thay đổi và cập nhật. Vòng đời phát triển sản phẩm nhanh hơn.
− Deployment nhanh hơn, độc lập giữa các service. Các team phát triển
nhanh và ít phụ thuộc lẫn nhau.
− Các issue nếu xảy ra trong 1 service thì sẽ có ít ảnh hưởng hơn tới các service
còn lại. Các service còn lại vẫn hoạt đồng bình thường (tuy nhiên khơng đảm
bảo hệ thống hoạt động đúng đắn, phải có các giải pháp để xử lý những vấn

đề này. Điều này cũng tương tự với kiến trúc Monolithic).
− Tận dụng được điểm mạnh đa ngôn ngữ để áp dụng cho từng service một
cách phù hợp.

3.2.2.2.4 Nhược điểm micro-service
− Rất phức tạp để thiết kế và triển khai. Yêu cầu kĩ thuật rất cao và đã có
kinh nghiệm về hệ thống.
− Performance chậm hơn do việc giao tiếp giữa các service.
− Yêu cầu kiến thức về domain, business tốt để phân chia thành các service
nhỏ sao cho phù hợp.
− Vấn đề liên quan đến vận hành và xử lý, nếu một hoặc nhiều service down
thì sẽ giải quyết thế nào.

Trần Thế Anh – Software Engineer

14


− Yêu cầu infrastructure phức tạp. Không chỉ quản lý các service trong
Microservice mà phải quản lý cả các hệ thống liên quan khác.
3.2.2.2.5 Khi nào sử dụng micro-service
− Một thách thức đối với việc sử dụng kiến trúc Microservices là khi nào nên
sử dụng nó.
− Khi phát triển phiên bản đầu tiên của ứng dụng, bạn thường không gặp phải
các vấn đề mà Microservices giải quyết. Hơn nữa, sử dụng một kiến trúc phân
tán, phức tạp sẽ làm chậm quá trình phát triển. Đây là một vấn đề rất lớn đối
với các start-up vì họ cần phát triển nhanh mơ hình kinh doanh cùng

ứng dụng đi kèm.
− Vì vậy, theo tơi, trừ khi bạn có một hệ thống q phức tạp để quản lý bằng
Monolithic Architecture, hoặc bạn xác định tương lai của ứng dụng sẽ trở
nên như vậy. Thì kiến trúc Monolithic vẫn đủ tốt đối với bạn.
3.2.2.2.6 Ta có thể liệt kê một trường hợp nên sử dụng kiến trúc này
− Team size lớn và rất lớn, đủ nguồn nhân lực có kiến thức và kinh nghiệm

để phát triển.
− Bài toán lớn, khả năng mở rộng và phát triển mạnh mẽ, đối tượng người
dùng là rất nhiều hoặc có tiềm năng phát triển cực lớn trong tương lai.
− Muốn thử sức mình với những điều mới mẻ.

3.2.3 Serverless
3.2.3.1 Khái niệm

− Là framework giúp xây dựng các ứng dụng theo dạng serverless
− Serverless là mơ hình thực thi điện toán đám mây mà các NCC sẽ quản lý
việc phân bố tài nguyên, giá cả. Có thể hiểu chúng ta xây dựng lên các ứng
dụng khả dụng, sẵn sàng lắng nghe và phản ứng lại với các sự kiện được
đưa ra bởi các dịch vụ

3.2.3.2 Serverless được xây dựng thế nào
3.2.3.2.1 Serverless được triển khai ở 2 mơ hình chính
3.2.3.2.1.1 BaaS – Backend as a Service
− Phần code logic chúng ta sẽ chuyển về phía FE. Cịn BE sử dụng API có sẵn
của bên thứ 3. Ví dụ 1 ứng dụng dự báo thời tiết thì ta sẽ lấy dữ liệu thời thiết

Trần Thế Anh – Software Engineer

15


thì có thể sử dụng API được Public bởi các nhà cung cấp bên thứ ba như
Google Weather API.
3.2.3.2.1.2 FaaS – Function as a Service

− Tự viết các API cho mục đích của mình. Thay vì deploy nó lên server như

mơ hình client-server thơng thường, chúng ta deploy code dưới dạng
RestAPI. Với mơ hình này, chúng ta chỉ việc code thôi, server và nơi lưu
trữ code bên thứ 3 sẽ tự quản lý
− Đây là cách mà các hàm được viết và thực thi khi sử dụng Serverless:
o Dev viết 1 func: func sẽ thực hiện 1 chức năng cụ thể trong app
o Dev define 1 event: event sẽ trigger tới func được viết ở trên. Event phổ
biến nhất là HTTP request
o Event đã được trigged: nếu event là 1 HTTP request, user sẽ trigger event

bằng cách click hoặc hành động tương tự.
o Func được thực thi: nhà cung cấp cloud sẽ kiểm tra xem instance của func

đã được chạy hay chưa. Nếu chưa, nó sẽ bắt đầu tạo 1 instance mới cho
func.
o Kết quả được gửi tới client: user có thể xem được các kết quả đã thực
thi bên trong app.
Trần Thế Anh – Software Engineer

16


3.2.3.2.1.3 Vì sao chọn Serverless
− Khơng cần tốn cơng sức bảo trì hệ thống
− Dễ dàng mở rộng quy mơ. Khi số lượng request tới ứng dụng của bạn tăng
cao, các nhà cung cấp bên thứ ba tự mở rộng thêm các tiến trình và tài
nguyên để cân bằng tải khi có nhiều request
− Có tính sẵn sàng và khả năng chịu lỗi cao.
− Chúng ta không cần phải đau đầu suy nghĩ và quyết định architecture phù
hợp vì nó được cung cấp mặc định bởi các nhà phát triển ứng dụng như
Google , Amazone,...

− Tiết kiệm chi phí, sử dụng tài nguyên bao nhiêu, chỉ cần trả tiền bấy nhiêu.
Nếu hệ thống khơng chạy thì chúng ta khơng mất phí. Với các doanh
nghiệp thì chi phí của serverless sẽ linh hoạt hơn so với việc thuê server
với cấu hình mặc định
3.2.3.2.1.4 Khi nào sẽ sử dụng Serverless
− Xử lý đa phương tiện: các thao tác xử lý hình ảnh, video với yêu cầu không
quá cao như cắt, nén, định dạng kích thước ảnh, tạo ảnh thumbnail, hoặc
chuyển đổi bộ mã của video để phù hợp với thiết bị tương ứng.
− Xử lý dữ liệu: tuỳ theo ngữ cảnh mà có thể ứng dụng như chatbot, IoT,…
lý do mà serverless thích hợp với mảng này vì với chatbot hay IoT chúng ta
không biết khi nào dữ liệu sẽ tới, khi nào sẽ cần xử lý dữ liệu nên chúng ta
không cần phải xây dựng máy chủ luôn luôn chạy và lãng phí ở thời gian
chờ.

3.3 CORS
3.3.1 Khái niệm Same origin policy

− Là 1 security concept quan trọng được thực hiện trên browser nhằm ngăn

chặn JS có thể tạo những request tới những domain khác. Hiểu đơn giản
Same origin là protocol, domain và port của liên kết truy cập là giống nhau.
− Dưới đây là cách để so sánh Same origin

Trần Thế Anh – Software Engineer

17


− Tại sao same origin tồn tại, thì các bạn cứ nghĩ đơn giản, nếu các bạn vô
Facebook, trong khi đó ở một tab khác các bạn mở một trang web chứa mã

độc. Tab Facebook sử dụng JavaScript để request lên server, nếu khơng có
same origin policy, JavaScript ở web chứa mã độc kia cũng có thể tạo
request lên server của Facebook với resource của tab Facebook, vì thế trình
duyệt phải có cơ chế để phân biệt JavaScript của nguồn nào thì được access
vào resource của nguồn nào.

3.3.2 Khái niệm CORS

− Là một cơ chế cho phép nhiều tài nguyên khác nhau (fonts, Javascript, v.v…)
của một trang web có thể được truy vấn từ domain khác với domain của trang

đó.

3.3.3 Client - Side CORS

− Vì lí do bảo mật, browser hạn chế các request HTTP giữa nhiều domain
khác nhau. Điều này có nghĩa là web app sử dụng api chỉ có thể gửi HTTP
request từ cùng một miền nơi web app được tải. Điều này gây ra khơng ít
hạn chế cho việc giao tiếp giữa client và server dù chúng đều là những
nguồn có thể tin tưởng được.

Trần Thế Anh – Software Engineer

18


− Trong quá trình phát triển web app, chúng ta thường truy cập data ở một
domain khác hay còn gọi là tên miền chéo. Để yêu cầu tài nguyên miền chéo
một cách an toàn, browser sử dụng 1 cơ chế gọi là CORS. Mặc dù browser
cấm truy cập domain chéo theo mặc định, nhưng chúng ta có thể sử dụng

CORS để nới lỏng hạn chế này.

Trần Thế Anh – Software Engineer

19


3.3.4 Server - Side CORS

− Ta phải thêm 1 field vào response là Access - Control - Allow - Origin,
giá tri của field này chỉ ra những trang web có thể truy cập vào tài nguyên

− Sau khi thêm field ACAO. Nếu gửi request
domain chéo thì nhận được response như sau

− Sau khi nhận phản hồi từ server, browser sẽ kiểm tra cơ chế CORS Access
- Control - Allow - Origin coi giá trị có bằng nhau hay khơng

Trần Thế Anh – Software Engineer

20


− Đến đây thì q trình xác thực thành cơng và dữ liệu từ domain chéo được
trả về cho phía client nếu ta không thêm field Access - Control - Allow –
Origin thì nhẫn được lỗi CORS như sau.

Trần Thế Anh – Software Engineer

21