Mai Trung Đức

mỗi 1 lần bạn load lại trang thì mọi thứ coi như clear hoàn toàn, nên nếu bạn muốn lưu lại menu của bạn giữa các lần load trang thì cách đơn giản nhất là đẩy cái trạng thái menu của bạn vào localStorage:

// Mỗi khi có thay đổi
localStorage.set('menu', menuClass) // menuClass là biến (string) chứa tên class css của bạn

// Khi trang được load lên
window.onload = function() {
  const menuClass = localStorage.get('menu')
 console.log(menuClass)
.....
}

về cái này thì bạn có thể tạo 1 network với option --ip-range, chọn range mà ko bị conflict với IP của công ty bạn. Sau đó lúc chạy container thì cho container của bạn join vào network này

Link: https://docs.docker.com/engine/reference/commandline/network_create/#options

bạn xem solution ở đây nhé, làm ngay từ phía client chứ chưa cần tới Laravel, ko quá phức tạp: https://usefulangle.com/post/46/javascript-get-video-thumbnail-image-jpeg-png

Có rất nhiều cách tiếp cận, có 1 cách mình nghĩ ngay tới bây giờ: dùng vue-lazyload. Bạn xem ví dụ về lazyload v-html ở đây: https://www.programmersought.com/article/46756522374/. Chúc bạn thành công

Mình trích dẫn example ở trang chủ React: https://reactjs.org/docs/update.html

Lý do khi làm việc với React bạn luôn phải clone array/object trước khi set state là bởi vì nếu bạn ko làm thế thì React sẽ "ko biết" để re-render lại, và bạn sẽ ko thấy cập nhật trên màn hình.

React re-render dựa vào việc so sánh state trước và sau khi thay đổi, nhưng nếu bạn thay đổi trực tiếp state (ví dụ là 1 object), thì ko có cách nào để React có thể check xem là state vừa thay đổi những cái gì, bởi vì state trước đó đã bị override mất rồi. Do đó luôn nhớ clone state trước khi thay đổi nhé bạn, kể cả dùng class component hay hooks

có cách nào update mà ko cần clone ra không vì nếu clone ra sẽ lãng phí bộ nhớ không cần thiết

Trong Javascript khi 1 biến mà ko bị reference đến (ko có ai truy cập đến nó) thì nó sẽ tự được garbage collector của Javascript thu hồi lại để tiết kiệm bộ nhớ nên bạn cũng ko cần quá lo lắng khi clone state vì hầu hết cái state của bạn sẽ chiếm ko đáng kể đến memory. Kể cả bạn có dùng các thư viện để thao tác với immutatable state trong React thì "bên dưới" cái chúng làm cũng là clone state (hoặc tương tự như vậy).

Demo: ví dụ bên dưới mình có 2 state, profile và text, để ý rằng khi update profile mình sửa trực tiếp state của nó:

function App() {
  const [profile, setProfile] = useState({
    name: 'ABC',
    age: 18
  })

  const [text, setText] = useState('Hello World')
  return (
    <div className="App">
      {profile.name} - {profile.age}
      <button onClick={() => {
        profile.name = 'DEF'
        console.log(profile)
      }}>Update Profile</button>

      <h1>{text}</h1>
      <button onClick={() => {
        setText('Hi')
      }}>Update Text</button>
    </div>
  );
}

Khi chạy lên, ta sẽ có 1 số quan sát như sau:

• bạn sẽ thấy rằng nếu click Update profile thì sẽ ko thấy content thay đổi trên màn hình, vì React ko biết là bạn vừa thay đổi state nên nó sẽ ko re-render.
• bạn cũng để ý thấy rằng dòng console.log đã in ra giá trị mới nhất của profile (nhưng UI thì ko cập nhật theo)
• nếu bạn tiếp tục bấm vào Update Text thì thấy rằng profile đã được update trên màn hình, lý do là vì khi click Update Text -> React sẽ re-render lại cả component và nó lấy ra state mới nhất của cả component là profile và text, do đó bạn thấy profile cũng đc update theo mặc dù ta vừa thay đổi chỉ mỗi text.

Sửa lại như sau thì code sẽ chạy đúng ko lỗi lầm gì:

    <button onClick={() => {
        setProfile({
          name: 'DEF',
          age: 21
        })
      }}>Update Profile</button>

// Hoặc
      <button onClick={() => {
        setProfile({
          ...profile,
          name: 'DEF'
        })
      }}>Update Profile</button>

Mình nhớ có lần đọc được bài về 1 vài solution update trực tiếp state mà React vẫn re-render, nhưng rất là chuối và nói chung trong thực tế ko nên đi theo các hướng như vậy. Bạn sẽ thấy kiểu "tự mình bắn vào chân mình" khi dính lỗi hoặc trong tương lai mình đọc lại code . Tốt nhất nên luôn follow pattern của React để tránh lỗi lầm

khi bạn dùng content type là multipart/form-data thì bạn cần phải truyền thêm boundary (thường là 1 cái unique ID nên là khác nhau giữa mỗi lần request)

Để gửi form data dùng Postman thay vì bạn tự set header thì bạn select chọn form-data như hình dưới là được, đó là cách đơn giản hơn cả, Postman lo phần generate boundary

nếu bạn ko muốn làm như vậy mà muốn tự set header thì bạn follow theo example sau: https://stackoverflow.com/a/23517227/7569705

theo a hiểu là e đang cài mysql-sql server ngoài (ko dùng mysql của XAMPP).

1. Nếu e vẫn muốn dùng Xampp, thì khi start Xampp e ko cần start SQL của nó, e vẫn chạy laravel, symfony ở folder htdocs của Xampp, update lại file .env trong project của e với những thông số của mysql-sql server là được
2. Nếu e muốn hoàn toàn bỏ Xampp, thì e chạy project của e ở đâu cũng được, follow theo document của Laravel/Symfony về cách tạo project mới (cần PHP, composer...)

chào bạn, theo mình bạn có 2 cách tiếp cận như sau:

1. Cách 1: cố gắng convert càng nhiều càng tốt đống lib bên trên dùng npm package nếu có thể.

Ở cách này bạn lên npm search xem những package trên cái nào có, và chuyển chúng sang dùng npm install..., ví dụ jQuery có trên npm, Sau đó bạn update file main.js hoặc file app.js, import chúng vào và cho chúng nó thành global:

import $ from 'jquery`
window.$ = $

Lí do phải cho chúng thành global bởi vì như bên trên code của bạn thì toàn bộ để là global, nên nếu bạn ko có bước window$... thì khi chạy lên sẽ thấy báo undefined

Nhược điểm lớn nhất của cách này đó là ko phải package nào cũng có trên npm, hoặc package cũng rất cổ và có thể ko tương thích nữa (ví dụ jquery sparkline). Và khả năng chạy lên có lỗi là rất cao

2. Cách 2: vẫn làm như cũ - load thư viện từ URL.

Copy toàn bộ đống lib như trong ảnh và để vào file Laravel blade của bạn, file Laravel blade ở đây chính là file nơi mà bạn load app VueJS = nơi có thẻ <script src=/js/app.js />:

<Load các thư viện trước khi load app.js>
...
<script src=/js/app.js />

Ưu điểm của cách này, đơn giản, ít gây lỗi và nhanh . Nhược điểm: ko tối ưu bằng cách 1

mình nghĩ là chẳng ai có thể đưa ra câu trả lời chắc nịch là CÓ hay KHÔNG cho bạn được.

Ae backend nào chuyên sâu về ngôn ngữ khác mà tự tin mình có thể cân được mọi loại web thì giới thiệu cho mọi người cùng học với nhé.

Cũng chẳng có ai tự tin mà khẳng định như vậy. càng làm nhiều lại càng ko dám khẳng định điều đó

Mình phải công nhận 1 sự thật đó là các system lớn, performance cao họ thường dùng các ngôn ngữ bậc thấp (C, C++) hay các ngôn ngữ đã phát triển từ lâu đời và có hệ sinh thái cực khủng như Java, .NET. Hệ sinh thái của các ngôn ngữ đó (VD: Java Spring) vô cùng lớn mạnh, enterprise, gần như cái gì cũng có package/lib có thể giải quyết đc vấn đề của bạn, chả cần nghĩ ngợi nhiều, cái gì cũng có lib xử lý.

Mình đi làm từ đầu tới giờ hầu hết chỉ focus vào JS, React/vue/angular, backend thì NodeJS. Mình cũng công nhận là về thực tế "có vẻ" NodeJS hơi lép vế khi ta phải build system lớn hoặc các ứng dụng enterprise. bởi vì NodeJS sinh cũng sau hơn các ngôn ngữ khác (c, cpp, java...) hệ sinh thái về system/enterprise cũng chưa có nhiều (mặc dù số lượng npm packages cũng vô cùng kinh khủng). nhưng điều đó chẳng nói lên rằng NodeJS ko thể build đc các app lớn, mọi ngôn ngữ theo lý thuyết đều có thể làm được (theo mình nghĩ như vậy). Và đó là lí do mình vẫn làm NodeJS tới giờ, đó là cái mình focus chính, còn đi làm thì các cty muôn hình vạn trạng, cần backend gì thì mình làm cái đó. Mình đâu thể join vào cty và cứ đòi làm cái ngôn ngữ mình thích. Mình có quen mấy a chị làm ở FB, GG, Twitter họ bảo trong đó vẫn có đầy dự án lớn dùng NodeJS (trên blog engineering của các cty đó cũng có rất nhiều bài giới thiệu về các system/app của họ dùng Node)

Mình nghĩ vấn đề của bạn là bạn đang cố gắng tìm ra 1 thứ có thể cân cả thế giới, nếu ai cũng như vậy, thì chắc đã ko có sự tồn tại của NodeJS/Rust/Ruby/Python... hay Go (1 trong nhữ ngôn ngữ rất hot bây giờ), mọi người cứ tập trung cho C, Cpp hay Java... cho nó cực kì kinh khủng là được, và như thế thì thế giới lập trình cũng buồn chán đi bao nhiêu. Cộng thêm bạn có chắc chắn là bạn làm được 1 ngôn ngữ cả đời ko? , bạn có chắc công ty tiếp theo bạn apply họ thích ngôn ngữ mà bạn chọn (vì bạn nghĩ nó cân đc cả thế giới). Và nó có thể làm bạn lỡ đi rất nhiều cơ hội., cũng làm cho bản thân bạn (có thể) cũng kém sáng tạo đi rất nhiều, vì cái gì cũng có rồi, chả cần nghĩ nhiều nữa. Làm như vậy thì sẽ hình thành tâm lý "ko cần nodejs, python... Cứ phang ngôn ngữ X của tôi, đỡ phải nghĩ, có hết rồi" (nghe đã thấy tẻ nhạt rồi ), 1 ví dụ thực tế là giờ rất nhiều người dùng React bởi vì nó to nhiều người dùng mà quên đi Vue + Angular cũng là những sự lựa chọn rất tuyệt vời, xong làm web nào cũng vậy ko cần biết app bé như con kiến hay app to, cứ phang React, bởi vì "quen" rồi.

Không có ngôn ngữ nào là giải pháp tốt nhất để giải quyết mọi vấn đề nhưng mình không cần tốt nhất, miễn làm được ra sản phẩm là được. Dù gì người dùng cũng chẳng quan tâm mình sử dụng công nghệ nào.

Chính xác, chẳng user nào người ta biết được tới bạn dùng công nghệ nào để phát triển nhưng bạn nói thế này thì ....

Câu chuyện chọn ngôn ngữ nào luôn là vấn đề muôn thuở mà mình thấy các bạn mới rất hay băn khoăn và mất thời gian vì nó. Chẳng ai dám tự tin khẳng định cái này hoặc cái kia tốt hơn mọi thứ, nó có thể góp phần tác động vào quan điểm/định hướng của người khác và làm cộng đồng kém phát triển đi. Bạn hãy chọn lấy 1 cái và làm nó, theo đuổi, kiên trì làm nó thật tốt nâng cao giá trị của bản thân, thay vì tự hỏi tìm ra 1 thứ vi diệu 1 cho tất cả.

Nhiều khi cũng phải take challenge thì bản thân mới có thể phát triển được phải ko

bên trên nó chỉ ăn vào subdomain của e, còn root domain thì báo lỗi.

Cách fix là e tạo riêng route cho root domain, nhớ để nó xuống bên dưới cái subdomain kia của e thì sẽ dc

câu trả lời ko mang tính bao hàm tất cả mọi trường hợp

Đoạn tìm hiểu của e về access token và refresh token là đúng đó e, đó cũng là những gì cơ bản nhất khi nói về access và refresh token

Về việc lưu refresh token trong DB

Như vậy em có 1 thắc mắc sau là khi token chết, thì làm cách nào để server kiểm tra tính hợp lệ của refresh token?

Sau khi access token expired thì e query lại lên server dùng refresh token, server nó sẽ check trong DB nếu cái refresh token của e match thì trả về access token mới cho e. (nhằm đảm bảo token đó đc generated bởi server, đc lưu lại trong DB của server)

Sau khi suy nghĩ thì em đưa ra câu hỏi tiếp là liệu refresh token vừa được client lưu ở local giống token và vừa được lưu trong DB?

Đó như bên trên a đã nói lúc server check refresh token của e trong DB nếu ko match với phía client của e gửi lên thì bắt login lại

Nếu như nó được lưu ở client rồi thì cần gì phải lưu ở DB trong khi server vẫn có thể kiểm tra tính hợp lệ và độ sống còn của nó giống thằng Token?

Câu này hay ). Một trong những mục đích người ta thường dùng khi lưu token (cả access token và refresh token) trong DB đó là để có thể revoke token bất kì lúc nào (huỷ bỏ token). Ví dụ như Facebook cho login trên nhiều thiết bị, mỗi thiết bị có 1 token, và mình muốn logout khỏi thiết bị nào thì revoke token của thiết bị đó. Lưu token trong DB thì cho phép ta quản lý được tokens (số lượng, ai sở hữu,...)

Và nếu như nó cũng được lưu như token thì chẳng phải token và refresh token nó gần như là 1 hay sao

Không phải . Access token là access token, refresh token là refresh token. E ko thể dùng Refresh token để truy cập protected resources được, và đó ko phải bản chất của refresh token.

Việc lưu token ở đâu là tuỳ thuộc vào use case của e và e chọn 1 cách hợp lý nhất cho project của mình.

Token để ở cookie muốn bảo mật thì set httpOnly=true (ko thể đc truy cập bằng javascript), set thêm secure=true (chỉ đc dùng nếu web load bằng https), set thêm sameSite nữa thì cũng thêm 1 lần bảo mật ở phía client. Đây cũng là cách a thấy mọi người dùng nhiều hơn cả

Lưu token ở trong DB sẽ cho ta thêm 1 số tính năng nữa như revoke token bất kì lúc nào mong muốn (trường hợp refresh token của e mà "sống" lâu quá thì đây cũng có thể là 1 giải pháp), hay để check chính xác là refresh token gửi bởi client match với DB phía server (để chắc chắn token đc generate bởi server và đc lưu vào DB cẩn thận). Nếu ko lưu token vào DB thì mỗi lần login mình sẽ "sign" và trả về access + refresh token về cho user, lần tới user request dùng các token đó thì mình vẫn check đc là nó có hợp lệ hay ko, nhưng mình ko thể biết được ngoài kia hiện tại có bao nhiêu token của user, loại nào bao nhiêu, account nào sở hữu nhiều tokens,.... Đương nhiên việc lưu token trong DB này sẽ thêm việc cho server của e (e phải quản lý cả tokens), mà token là thứ user tạo ra liên tục, 1 account có thể có hàng chục/trăm token, nên nếu ko có cơ chế để remove unused/expired token thì DB của e lại overload (yes, lại thêm việc) .

Chào bạn, mình nghĩ cũng tuỳ trường hợp.

Nếu bạn có 1 trang blog, nơi bạn lấy response từ phía server và display nội dung của post theo dạng html:

// response
{
  "id": 1,
  "post": "<img src='x' onerror='alert(1)'>"
}

Và ở phía frontend:

<div id="post"></div>

<script>
  document.getElementById("post").innerHTML = response.post
</script>

Như bên trên thì vẫn XSS đc bình thường thôi à. Mình nghĩ nếu app của bạn có trường hợp như vậy thì cách tốt nhất là sanitize (làm sạch) data từ phía client trước khi gửi lên server và cả sanitize data lúc nhận đc từ phía server nữa (bước làm ở phía server luôn cần phải có)

về câu hỏi của bạn:

• Lí do trong tutorial kia bạn ko thấy người ta dùng client_id, client_secret bởi vì tutorial đó họ dùng personal access token (họ cũng nói trong bài đó bạn). Kiểu này là khi mình cần tạo cho user 1 cái access token mà ko cần tới flow của oauth đó là chuyển hướng (redirect) lấy authorization code và exchange lấy access token,....và do vậy user có thể gọi API tới backend "xin" access token trực tiếp mà ko cần redirect. Trường hợp này thường dùng nếu bạn muốn cho user test nhanh API hoặc dùng thử nhanh 1 feature nào đó. Còn bình thường đã nói tới laravel passport (oauth) thì thường ngừoi ta sẽ dùng redirect flow (chuyển hướng, lấy authorization code để đổi lấy access token) và lúc đó ta sẽ cần tới client_id và client_secret
• Khi token của bạn sau ngày thứ 15 hết hạn thì đến ngày thứ 16 bạn đơn giản là dùng cái refresh token gọi API lại server để exchange lấy access token mới thôi . Thường người ta sẽ set expiration time cho refresh token lâu hơn access token:

    Passport::tokensExpireIn(now()->addDays(15));
    Passport::refreshTokensExpireIn(now()->addDays(30));
    Passport::personalAccessTokensExpireIn(now()->addMonths(6));

Còn gọi vào API nào để lấy access token mới thì ở docs của Laravel Passport phần #Refreshing-tokens đã nói rất rõ rồi nhé

Nếu được thì bạn hãy dùng Docker nhiều nhất có thể để chạy các app của bạn, nó sẽ giúp giảm rất nhiều vấn đề với môi trường và tự động được nhiều công đoạn sau này. vậy nên mình recommend là bạn cài Docker vào VPS và setup LAMP stack của bạn bên trong Docker

React hay Vue hay Angular, 1 khi đã build ra các file static là bạn có thể chạy được, lí do bạn mở file index.html thấy màn hình trắng đơn giản là gì ở file build các đoạn mà link tới file css hoặc js được mặc định dùng đường dẫn tương đối kiểu /static/css/app.css, kiểu đó bạn cần có 1 webserver để chạy (nodejs, nginx) thì nó mới hiểu được.

Thế ko có webserver mà vẫn muốn chạy thì làm thế nào?

Đơn giản là bạn mở file index.html lên tìm và thay thế các đoạn mà link tới file css, js có tiền tố /static/ bạn đổi thành ./static là được. F5 lại trình duyệt là thấy app chạy bình thường:

Thế nhưng khi chạy lên, bạn có thể thấy là các file ảnh, thì không hiển thị, lí do vì trong code React bạn import các file đó vào và sau quá trình build thì các đường dẫn đều ở dạng kiểu tương đối /static/media/image.svg,... (mình cũng chưa tìm hiểu nhiều lắm về cơ chế build này của webpack). Do vậy khi bạn chỉ mở app lên bằng file index.html thông thường thì sẽ ko thấy ảnh ọt j cả.

Vậy nên khi deploy ta mới cần tới webserver để có thể serve app React (Node-Express, Python-Flask, ... hoặc nginx). Bất kì webserver nào cũng đc. Vấn đề quan trọng nữa nên dùng web server khi chạy app ở production là các webserver sẽ support các file static rất tốt (cache chẳng hạn), nên hiệu năng sẽ tốt hơn.

bạn tìm tới process đang chạy Ngrok và kill nó đi nhé, có nhiều cách, 1 trong các cách là bạn chạy command top để list ra danh sách các process đang chạy, sẽ thấy dạng như sau:

Sau đó bạn kill process ngrok đi:

kill -9 <process_id> # trong ảnh process_id=23391

bạn nên setup user chạy cronjob bằng user mà own folder app laravel, 1 cách để kiểm tra đó là, bạn cd vào folder app laravel, check quyền trong đó:

ls -l

---->>>
drwxr-xr-x   13 maitrungduc  staff     416  3 Aug 21:52 app
-rwxr-xr-x    1 maitrungduc  staff    1686  3 Aug 21:52 artisan
drwxr-xr-x    4 maitrungduc  staff     128  1 Aug 12:43 bootstrap
-rw-r--r--    1 maitrungduc  staff    1601  3 Aug 21:52 composer.json
-rw-r--r--    1 maitrungduc  staff  189309  4 Nov 10:08 composer.lock
......

Bạn thấy in ra user nào thì bạn chạy bằng user đó, như ở trên user của mình là maitrungduc, sau đó bạn setup cronjob bằng user đó thì sẽ ko gặp lỗi permission, vì khi đó log tạo ra sẽ có quyền đúng bằng maitrungduc. Và để setup cronjob cho non-root user trên Ubuntu thì bạn làm như sau:

crontab -u maitrungduc -e

Như bên trên có 1 bạn đã comment, bạn thử đổi url của bạn sang https xem nhé. nếu bạn đang test ở local, cách theo mình thấy dễ nhất và nhanh nhất để có HTTPS là bạn dùng Ngrok.

Vì bình thường khi mình code Android (native, ko phải RN) thì mình cũng phải thêm network_security_config hoặc dùng HTTPS thì mới đc

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">192.168.1.135</domain>
    </domain-config>
</network-security-config>

làm gì có lỗi gì đâu nhỉ.

Mình đã thử demo trực tiếp, chạy ngon.

App.vue (parent):

<template>
  <div id="app">
    <ExampleComponent
      @has-error="hasError"  
    />
  </div>
</template>

<script>

import ExampleComponent from './ExampleComponent'
export default {
  components: {
    ExampleComponent
  },
  methods: {
    hasError(error) {
      console.log('Receive Error from child')
      console.log(error)
    }
  }
}
</script>

ExampleComponent.vue (child):

<template>
    <div class="container">
       Hello world
    </div>
</template>

<script>
import axios from 'axios'
    export default {
       mounted() {
            axios.get('httpsss://randomuser.me/api/')
            .then((response) => {
                console.log(response.data)
            }).catch(error => {
                this.$emit('has-error', error)
            }).finally(() => {
            })
        },
    }
</script>

Kết qủa:

Bạn check lại khéo cái catch của bạn còn chưa chạy vào ấy chứ

1 trong những cách đơn giản là bạn làm ở phần webserver, ví dụ nginx:

location ~* \.(jpg|jpeg|png)$ {
    return 301 https://another_site.com$request_uri;
}

nếu bạn dùng Apache thì search cách làm tương tự