5 Kết luận & Hướng phát triển
3.13 Sơ đồ khối bên nhận yêu cầu lấy vị trí thiết bị và thông tin thuê
này, nếu có tương tác với thiết bị thì chương trình sẽ phát âm thanh cảnh báo và khóa màn hình.
Giải pháp cho tính năng bảo mật ứng dụng là ẩn icon ứng dụng ngoài màn hình điện thoại hoặc chuyển ứng dụng vào ứng dụng hệ thống nhằm tránh việc gỡ cài đặt thông thường. Để ẩn icon ứng dụng, chỉ cần thực thi chuyển ứng dụng vào trạng thái “disable” mà ứng dụng vẫn tiếp tục hoạt động. Khi hiển thị lại icon, chỉ cần chuyển lại trạng thái về “enable” là ứng dụng sẽ xuất hiện icon trên màn hình điện thoại.
3.3.5 Tương tác service
Người dùng muốn sử dụng ứng dụng phải thực thi các thao tác đăng ký, đăng nhập để hệ thống kiểm soát. Service được xây dựng để cung cấp các cơ
chế cho người dùng đăng ký, đăng nhập để quản lý sau này. Và trong tương lai chúng tôi sẽ tiếp tục phát triển các chức năng điều khiển, quản lý từ giao diện web và người dùng có thể điều khiển điện thoại của mình thông qua web.
Phương thức giao tiếp giữa client và server là HTTP. Web service sử dụng giao thức HTTP cung cấp 4 phương thức GET, POST, PUT, DELETE. Trong ứng dụng này chỉ sử dụng phương thức POST.
POST: được sử dụng để gởi yêu cầu từ client lên server yêu cầu các thông tin đăng nhập, đăng ký, thay đổi mật khẩu, yêu cầu server gởi SMS.
Dữ liệu trả về từ server dạng JSON, phía client phải phân tích các trạng thái gói tin (HTTP Status) và dữ liệu trả về để xác nhận lệnh và thực thi (nếu thỏa điều kiện thực thi).
Phương thức URI Chức năng
POST /api/users Đăng ký tài khoản mới
POST /api/users/login Đăng nhập vào hệ thống
POST /api/users/forgotpassword Nhận mật khẩu mới
POST /api/users/sendsms Yêu cầu gởi SMS
Bảng 3.5: Bảng mô tả đường dẫn yêu cầu các chức năng và phương thức tươngứng ứng
Giải thuật xử lý bên Server
Sau khi nhận các gói tin yêu cầu từ client, server sẽ phân tích các yêu cầu này và thực thi tùy chức năng.
Đối với yêu cầu đăng ký tài khoản người dùng mới, phía server sẽ tiến hành kiểm tra các điều kiện như tài khoản hoặc email đã tồn tại hay chưa? Sau đó sẽ tiến hành thêm mới vào cơ sở dữ liệu và gởi email xác nhận đăng ký thành công về cho người dùng. Đồng thời cũng sẽ gởi lại gói tin phản hồi yêu cầu đăng ký từ client để thông báo trạng thái đăng ký (tài khoản, email đã tồn tại, đăng ký thất bại).
Đối với yêu cầu đăng nhập, sau khi nhận được gói tin yêu cầu đăng nhập từ client kèm với thông tin tài khoản và mật khẩu đã được mã hóa, server tiến hành chứng thực trong cơ sở dữ liệu và gởi phản hồi về client thông báo trạng thái đăng nhập thành công hay thất bại.
Đối với yêu cầu thay đổi mật khẩu, sau khi nhận được gói tin yêu cầu thay đổi mật khẩu kèm với email người dùng, server tiến hành chứng thực email có trong cơ sở dữ liệu hay không ? Nếu có thì server sẽ gởi email về email được gởi lên kèm với mật khẩu mới. Sau đó thông báo trạng thái về cho client. Người
dùng phải kiểm tra trong hộp thư của mình để nhận mật khẩu mới nếu yêu cầu thay đổi mật khẩu thành công. Người dùng có thể sử dụng mật khẩu này để đăng nhập vào chương trình, hoặc đăng nhập vào hệ thống từ phía giao diện web và thực thi thay đổi mật khẩu trực tiếp từ web. Sơ đồ khối mô tả quy trình xử lý các yêu cầu đăng ký, đăng nhập, nhận mật khẩu mới như hình 3.14. Theo
Bắt đầu Nhận yêu cầu từ Client Đăng ký Email & Username Lưu vào database Lỗi thực thi (500/501) Quên mật khẩu Đăng nhập Chứng thực Chứng thực Gởi email xác nhận
Tài khoản hoặc
email đã tồn tại Gởi phản hồi
Kết thúc
Chứng thực sai (401) Thành công (200)
Yêu cầu không tồn tại (404) Sai Sai Đúng Đúng Đúng Sai Đã có Chưa có Đúng Sai Sai Đúng (E m ai l) Thành công Thất bại
Tạo mật khẩu mới
Gởi SMS Sai
Hình 3.14: Sơ đồ khối phía server nhận và xử lý yêu cầu đăng ký, đăng nhập, nhận lại mật khẩu
hình 3.14, sau khi nhận được yêu cầu từ client, tùy từng yêu cầu mà phía server sẽ xử lý và gởi phản hồi. Các mã trạng thái tương ứng trong quá trình xử lý sẽ được gởi phản hồi kèm các thông tin thông báo. Phía client sẽ dựa vào các mã trạng thái này, hoặc các thông báo gởi về để xác định phần xử lý tiếp theo. Danh sách các mã trạng thái trả về cho client:
• 200: Thực thi thành công.
• 401: Chứng thực thất bại.
• 404: Không tìm thấy service yêu cầu (sai đường dẫn).
• 500: Lỗi server không insert vào cơ sở dữ liệu được.
• 501: Lỗi không thực thi được.
Đối với yêu cầu gởi SMS, sau khi nhận được yêu cầu từ phía client, server sẽ tiến hành chứng thực username và password nhận được. Sau khi chứng thực thành công, server sẽ tiến hành thêm một record vào cơ sở dữ liệu với trạng thái “send”. Sau đó, phía tổng đài gởi SMS sẽ truy cập cơ sở dữ liệu này để tìm kiếm các record có trạng thái “send” và gởi chúng đến số điện thoại cần nhận. Đồng thời cập nhật lại trạng thái record trong cơ sở dữ liệu. Sơ đồ khối mô tả cho giải thuật xử lý yêu cầu gởi SMS khi thay SIM được mô tả trong hình 3.15. Trong sơ đồ trong hình 3.15, tổng đài Ozeki sau khi kích hoạt sẽ luôn hoạt động sau khoản thời gian cài đặt sẽ quét cơ sở dữ liệu để tìm các record mới thêm vào với trạng thái “send” (trạng thái cần gởi SMS). Nếu tìm thấy, sẽ tự động gởi phần nội dung tin nhắn đến số điện thoại người nhận (các giá trị này là các cột trong bảng cở sở dữ liệu mà giá trị của nó ta phải thêm vào). Thao tác này được gọi thực thi sau khi phía server tiến hành thêm record mới vào cơ sở dữ liệu, với giá trị các cột nội dung và người nhận lấy được từ phía client.
Bắt đầu Nhận yêu cầu từ Client Gởi SMS Chứng thực Kết thúc Thêm record trong databases với trạng thái “send”
Tổng đài Ozeki quét cơ sở dữ liệu các record có trạng thái
“send” Có record mới Send SMS và cập nhật trạng thái record. Đúng Sai Đúng Sai Đúng