Next.js: लॉगिन / प्रमाणीकरण उदाहरण जोड़ें

सुझाव: उदाहरण को पूरा करने के लिए Redux और JWT का उपयोग करें

मैं इसके लिए एक उदाहरण पर काम कर रहा हूं। वर्तमान में मेरे उच्च स्तरीय घटक (जहां मैं यह जांचने की योजना बना रहा हूं कि उपयोगकर्ता प्रमाणीकृत है और लॉगिन पृष्ठ पर रीडायरेक्ट नहीं है)

तो मेरे पास तैराकी से काम करने का अधिकार है। जैसा कि कहीं और उल्लेख किया गया है, यह केवल क्लाइंट-साइड है, जो अंततः केवल आधी लड़ाई है।

"बहुत सुरक्षित"

Php की तरह, Next की परमाणु इकाई पृष्ठ है। सबसे अच्छी विशेषताओं में से एक यह है कि यह आलसी प्रत्येक पृष्ठ को केवल तभी लोड करता है जब उसका अनुरोध किया जाता है। क्लाइंट-साइड केवल ऑथ के साथ लेकिन सर्वर-रेंडरिंग के साथ, उस संरक्षित पृष्ठ के लिए जेएस वास्तव में ब्राउज़र द्वारा डाउनलोड किया जाता है। भविष्य में जब नेक्स्ट सर्वर वर्कफ्लो जोड़ता है, तो उम्मीद है कि आप इसे पूरी तरह से रोकने के लिए सर्वर पर रेंडर और रीडायरेक्ट को ब्लॉक करने में सक्षम होंगे। इसके लिए कुकीज़, सत्र और AFAIK सत्र स्टोर की आवश्यकता होगी, लेकिन यह इस तरह के हाइब्रिड ऐप्स करने की लागत है।

प्रामाणिक उदाहरण

मान लें कि आपके पास जेडब्ल्यूटी-सुरक्षित एपीआई है जिसमें ब्याज के दो अंतिम बिंदु हैं: /token और /me । /token ईमेल/पासवर्ड क्रेडेंशियल स्वीकार करता है और एक हस्ताक्षरित JWT ( id_token ) देता है जबकि /me JWT-प्रमाणित उपयोगकर्ता से संबंधित प्रोफ़ाइल जानकारी देता है। मैंने Auth0 के लॉक से निम्नलिखित AuthService.js को अनुकूलित किया (ईवेंट एमिटर को हटा रहा है, हालांकि यह सबसे बुरा विचार नहीं है)। यह लगभग सभी जेडब्ल्यूटी टोकन हैंडलिंग को निकालता है ताकि इसे लॉगिन पेज पर और उच्च ऑर्डर घटक में भी इस्तेमाल किया जा सके (उस पर बाद में और अधिक)।

// utils/AuthService.js
export default class AuthService {
  constructor(domain) {
    this.domain = domain || 'http://localhost:5000'
    this.fetch = this.fetch.bind(this)
    this.login = this.login.bind(this)
    this.getProfile = this.getProfile.bind(this)
  }

  login(email, password) {
    // Get a token
    return this.fetch(`${this.domain}/token`, {
      method: 'POST',
      body: JSON.stringify({
        email,
        password
      })
    }).then(res => {
      this.setToken(res.id_token)
      return this.fetch(`${this.domain}/user`, {
        method: 'GET'
      })
    }).then(res => {
      this.setProfile(res)
      return Promise.resolve(res)
    })
  }

  loggedIn(){
    // Checks if there is a saved token and it's still valid
    const token = this.getToken()
    return !!token && !isTokenExpired(token) // handwaiving here
  }

  setProfile(profile){
    // Saves profile data to localStorage
    localStorage.setItem('profile', JSON.stringify(profile))
  }

  getProfile(){
    // Retrieves the profile data from localStorage
    const profile = localStorage.getItem('profile')
    return profile ? JSON.parse(localStorage.profile) : {}
  }

  setToken(idToken){
    // Saves user token to localStorage
    localStorage.setItem('id_token', idToken)
  }

  getToken(){
    // Retrieves the user token from localStorage
    return localStorage.getItem('id_token')
  }

  logout(){
    // Clear user token and profile data from localStorage
    localStorage.removeItem('id_token');
    localStorage.removeItem('profile');
  }

  _checkStatus(response) {
    // raises an error in case response status is not a success
    if (response.status >= 200 && response.status < 300) {
      return response
    } else {
      var error = new Error(response.statusText)
      error.response = response
      throw error
    }
  }

  fetch(url, options){
    // performs api calls sending the required authentication headers
    const headers = {
      'Accept': 'application/json',
      'Content-Type': 'application/json'
    }

    if (this.loggedIn()){
      headers['Authorization'] = 'Bearer ' + this.getToken()
    }

    return fetch(url, {
      headers,
      ...options
    })
    .then(this._checkStatus)
    .then(response => response.json())
  }
}

सुरक्षा पृष्ठों को सरल बनाने के लिए अगला एक HOC है। संवेदनशील जानकारी के अवांछित फ्लैश को रोकने के लिए, पेज पहले रेंडर पर Loading... सर्वर-रेंडर करेगा जबकि रिएक्ट बूट अप/लोकलस्टोरेज से टोकन पढ़ता है। इसका मतलब है कि संरक्षित पृष्ठ एसईओ नहीं करेंगे, जो शायद अभी तक ठीक है, लेकिन निश्चित रूप से इष्टतम नहीं है।

// utils/withAuth.js - a HOC for protected pages
import React, {Component} from 'react'
import AuthService from './auth'

export default function withAuth(AuthComponent) {
    const Auth = new AuthService('http://localhost:5000')
    return class Authenticated extends Component {
      constructor(props) {
        super(props)
        this.state = {
          isLoading: true
        };
      }

      componentDidMount () {
        if (!Auth.loggedIn()) {
          this.props.url.replaceTo('/')
        }
        this.setState({ isLoading: false })
      }

      render() {
        return (
          <div>
          {this.state.isLoading ? (
              <div>LOADING....</div>
            ) : (
              <AuthComponent {...this.props}  auth={Auth} />
            )}
          </div>
        )
      }
    }
}

// ./pages/dashboard.js
// example of a protected page
import React from 'react'
import withAuth from  '../utils/withAuth'

class Dashboard extends Component {
   render() {
     const user = this.props.auth.getProfile()
     return (   
         <div>Current user: {user.email}</div>
     )
   }
}

export default withAuth(Dashboard) 

लॉगिन पेज एचओसी का उपयोग नहीं कर सकता क्योंकि यह अभी खड़ा है, क्योंकि लॉगिन सार्वजनिक होना चाहिए। तो यह सीधे AuthService का एक उदाहरण बनाता है। आप साइनअप पेज के लिए भी कुछ ऐसा ही करेंगे।

// ./pages/login.js
import React, {Component} from 'react'
import AuthService from '../utils/AuthService'

const auth = new AuthService('http://localhost:5000')

class Login extends Component {
  constructor(props) {
    super(props)
    this.handleSubmit = this.handleSubmit.bind(this)
  }

  componentDidMount () {
    if (auth.loggedIn()) {
      this.props.url.replaceTo('/admin')   // redirect if you're already logged in
    }
  }

  handleSubmit (e) {
    e.preventDefault()
    // yay uncontrolled forms!
    auth.login(this.refs.email.value, this.refs.password.value)
      .then(res => {
        console.log(res)
        this.props.url.replaceTo('/admin')
      })
      .catch(e => console.log(e))  // you would show/hide error messages with component state here 
  }

  render () {
    return (
      <div>
         Login
          <form onSubmit={this.handleSubmit} >
            <input type="text" ref="email"/>
            <input type="password" ref="password"/>
            <input type="submit" value="Submit"/>
          </form>
      </div>
    )
  }
}

export default Login

Airbnb की प्रतिक्रिया-शैली से प्रेरित होकर, मैंने next-with-auth lib पर भी काम करना शुरू कर दिया, जो एक फ़ंक्शन होगा जो पृष्ठों पर उपयोग किए जाने के लिए एक HOC लौटाएगा। मैंने AuthService और इस एचओसी के विलय के साथ भी खेला। एक समाधान यह हो सकता है कि इस एचओसी को घटक के अतिरिक्त एक अनुमति स्तर फ़ंक्शन को रेडक्स कनेक्ट जैसे तर्क के रूप में स्वीकार किया जाए। भले ही, मेरे दिमाग में, आप इस तरह next-with-auth उपयोग करेंगे:

// ./utils/withAuth.js
import nextAuth from 'next/auth'
import parseScopes from './parseScopes'

const Loading = () => <div>Loading...</div>

export default nextAuth({
  url: 'http://localhost:5000',
  tokenEndpoint: '/api/token',
  profileEndpoint: '/api/me',
  getTokenFromResponse: (res) => res.id_token,
  getProfileFromResponse: (res) => res,
  parseScopes,
})

Redux के साथ यह सब करना अनावश्यक रूप से जटिल लग रहा था, लेकिन मूल रूप से आप विकी उदाहरण का अनुसरण कर सकते हैं, लेकिन AuthService को क्रियाओं (लॉगिन और लॉगआउट) में स्थानांतरित कर सकते हैं और एक उपयोगकर्ता रेड्यूसर रख सकते हैं। आप केवल क्लाइंट पर इन क्रियाओं को कॉल कर सकते हैं, क्योंकि सर्वर पर स्थानीय स्टोरेज नहीं है, इसलिए आपको इसे अपने कार्यों में जांचना होगा। अंततः, redux store को वैसे भी window पर रखा जाता है। तो आप संदर्भ का उपयोग करने के बजाय उपयोगकर्ता को window पर अच्छी तरह से कैश कर सकते हैं। यदि आप redux नहीं चाहते हैं, तो आप react-broadcast भी आज़मा सकते हैं।

अंत में, next/server जहाजों को #25 के अनुसार मानकर। next-with-auth मिडलवेयर + एक एचओसी के साथ डेवलपर से जटिल जटिल स्थानीय स्टोरेज बनाम कुकी सामग्री को अमूर्त कर सकता है। यह टोकन रिफ्रेशिंग को भी हैंडल कर सकता है।

इसे आजमाने के लिए उत्साहित! बेयरबोन कार्यान्वयन के लिए धन्यवाद :)

@jaredpalmer मैं कुछ इसी तरह काम कर रहा हूँ। जब किसी घटक को सर्वर साइड दिया जाता है तो आपका AuthService कैसे काम करता है? सर्वर को JWT तक पहुंच की आवश्यकता होगी, लेकिन इसे स्थानीय भंडारण से नहीं पढ़ा जा सकता है।

@amccloud यह नहीं करता है। यही है सारा मसला। एचओसी संरक्षित मार्गों पर <div>Loading..</div> करता है और टोकन को पढ़ना चाहिए और यह तय करना चाहिए कि componentDidMount में रीडायरेक्ट करना है या नहीं। इसके लिए जिस तरह से आप इसे चाहते हैं और सर्वर-साइड प्रस्तुत करना चाहते हैं, इसके लिए # 25 की आवश्यकता है, या कम से कम जेडब्ल्यूटी AFAIK के मूल्य के साथ कुकी सेट करने की क्षमता है।

मैंने कुकी सेट करने के लिए कुकी-जेएस का इस्तेमाल किया, लेकिन यह एक हैक का थोड़ा सा है ..
बात यह है: यदि आप कुकी नहीं भेजते हैं, तो आप प्रमाणित मार्गों में नेक्स्टज और सर्वर साइड रेंडरिंग के सभी लाभ खो देते हैं

@jaredpalmer यह बहुत अच्छा है! प्रयास करने के लिए धन्यवाद। मैं अगले दिनों में आपके उदाहरण को लागू करने का प्रयास करूँगा (या यदि आप चाहें तो इसे करने में आपकी सहायता कर सकते हैं)

यो! मैंने यहाँ nextjs और auth0 के साथ एक उदाहरण प्रकाशित किया: https://github.com/luisrudge/next.js-auth0
इसमें एक मुख्य लेआउट की अवधारणा है और "सुरक्षित पृष्ठ" भी हैं जो केवल तब लोड होते हैं जब उपयोगकर्ता प्रमाणित होता है।
मुझे बताएं कि आप क्या सोचते हैं

@luisrudge अद्भुत। मैं क्लोनिंग कर रहा हूं और कुछ बदलाव कर रहा हूं लेकिन बहुत अच्छा लग रहा है

ठंडा! आपको क्या लगता है कि इसमें क्या कमी है? आप क्या बदलाव सोच रहे हैं?

सूर्य, नवम्बर 6, 2016 को 1:12 PM पर -0200 पर, "दान Zajdband" < [email protected] [email protected] > ने लिखा:

@luisr udgehttps://github.com/luisrudge अद्भुत। मैं क्लोनिंग कर रहा हूं और कुछ बदलाव कर रहा हूं लेकिन बहुत अच्छा लग रहा है

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे Gi tHubhttps://github.com/zeit/next.js/issues/153#issuecomment -258687108 पर देखें, या पढ़ने को म्यूट करें https://github.com/notifications/unsubscribe-auth/ AA5cE8NIsvQ_ITjc1gArTFgNXzEda4TSks5q7e5NgaJpZM4KkJmi।

1) लाइनिंग के लिए standard का उपयोग करना (इसलिए यह हर उस चीज के अनुरूप है जिसे हम आगे बना रहे हैं)
2) @rauchg . द्वारा अनुरोधित मल्टी-टैब समर्थन जोड़ना
3) सीएसएस भाग को सरल बनाया जा सकता है

मैं आपको एक जनसंपर्क भेजूंगा :)

मल्टी टैब सपोर्ट से आप क्या समझते हैं?

सूर्य, नवम्बर 6, 2016 को 1:16 PM पर -0200 पर, "दान Zajdband" < [email protected] [email protected] > ने लिखा:

1) लाइनिंग के लिए मानक का उपयोग करना (इसलिए यह हर उस चीज़ के अनुरूप है जिसे हम आगे बना रहे हैं)
2) @rauchghttps :
3) सीएसएस भाग को सरल बनाया जा सकता है

मैं आपको एक जनसंपर्क भेजूंगा :)

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे Gi tHubhttps://github.com/zeit/next.js/issues/153#issuecomment -258687373 पर देखें, या पढ़ने को म्यूट करें https://github.com/notifications/unsubscribe-auth/ AA5cE1A6jq4KZc9_ynukTCI4mU-rdsNaks5q7e81gaJpZM4KkJmi।

आपके पास 2 खुले टैब हैं, 1 पर लॉगआउट करें, दूसरे पर स्वचालित रूप से लॉग आउट करें

आह। यह बहुत अच्छा है!

सूर्य, नवम्बर 6, 2016 को 1:21 PM पर -0200 पर, "दान Zajdband" < [email protected] [email protected] > ने लिखा:

आपके पास 2 खुले टैब हैं, 1 पर लॉगआउट करें, दूसरों पर स्वचालित रूप से लॉग आउट करें

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे Gi tHubhttps://github.com/zeit/next.js/issues/153#issuecomment -258687707 पर देखें, या पढ़ने को म्यूट करें https://github.com/notifications/unsubscribe-auth/ AA5cE9e2DA4_GgNQIVTMp0hx74G-6RmUks5q7fBfgaJpZM4KkJmi।

नमस्ते @luisrudge मैंने आपको परिवर्तनों के साथ एक पीआर भेजा है https://github.com/luisrudge/next.js-auth0/pull/2

ऐसा करने के लिए आपका बहुत-बहुत धन्यवाद <3

बीटीडब्ल्यू यह परिणाम है:

@improunciable @luisrudge शानदार कार्यान्वयन! यदि आप इसे Auth0 के बिना उपयोग करना चाहते हैं, तो ऐसा लगता है कि आपको केवल ./utils dir में फ़ाइलों को बदलने की आवश्यकता होगी, शायद केवल lock.js । मैं इसे जल्द ही आजमाऊंगा। बीटीडब्ल्यू मल्टी-टैब कमाल का दिखता है

@ugiacoman मैंने passwordless.net के साथ एक छोटा सर्वर लागू करना शुरू कर दिया है, मुझे बताएं कि क्या आप मेरे कोड को शुरुआती बिंदु के रूप में प्राप्त करना चाहते हैं

@improunciable यह बहुत अच्छा होगा! मैं वास्तव में ट्विटर फैब्रिक के अंकों के साथ कुछ ऐसा ही करने जा रहा था।

@impronuncible मैं सुझाव

धन्यवाद @improunciable ❤️

@ugiacoman हाँ, auth0 निर्भरता को हटाना बहुत आसान है। मैंने इसका इस्तेमाल किया क्योंकि मैं ऑथ को संभालने के लिए एक अलग एपीआई नहीं चाहता था

@jaredpalmer जहाँ तक मुझे पता है, #25 होना बहुत अच्छा होगा लेकिन अवरुद्ध नहीं हो रहा है? मेरा मतलब है कि हम सर्वर साइड की पहुंच है req में getInitialProps तो कुछ भी नहीं रोकता है को लागू करने cookie-parser यह करने के लिए? सर्वर-साइड प्रमाणीकरण और सत्र प्रबंधन मेरे लिए बिल्कुल नया है

localStorage पर विचार करते हुए बीटीडब्ल्यू सर्वर-साइड का उपयोग नहीं किया जा सकता है, क्या कुकीज़ सर्वर-साइड सत्र रखने का एकमात्र तरीका है? मुझे एक अस्पष्ट याद है कि यह सबसे सुरक्षित नहीं हो सकता है? लेकिन क्या कोई और विकल्प है?

@sedubois

अगर ठीक से किया जाए तो कुकी दृष्टिकोण बहुत सुरक्षित हो सकता है। निम्नलिखित करना काफी तुच्छ है:

• httpOnly ध्वज का उपयोग करें (जावास्क्रिप्ट को कुकी तक पहुंचने से रोकता है)
• सुरक्षित ध्वज का उपयोग करें (केवल https अनुरोधों के लिए कुकी सेट करें)
• हस्ताक्षरित कुकीज़ (कुकी के स्रोत की पुष्टि करें)

जब आप सीधे सर्वर पर प्रमाणीकरण जानकारी तक पहुँच सकते हैं तो एक बहुत ही महत्वपूर्ण विलंबता लाभ भी होता है।

हमें इस उदाहरण को examples/ में ले जाना चाहिए, मैं देखूंगा कि मैं किसके साथ आ सकता हूं

मैंने निम्नलिखित तरीके से एक कस्टम एक्सप्रेस सर्वर में नेक्स्टज को लपेटकर आइसोमॉर्फिक कुकीज़ के लिए react-cookie का उपयोग करने का प्रबंधन किया है:

const express = require('express')
const next = require('next')
const cookie = require('react-cookie')
const cookieParser = require('cookie-parser')

const app = next({ dev: true, dir: process.cwd() })
const handle = app.getRequestHandler()

app.prepare().then(() => {
  const server = express()
  server.use(cookieParser())       // <---- this line

  server.get('*', (req, res) => {
    cookie.plugToRequest(req, res) // <---- this line
    return handle(req, res)
  })

  server.listen(3000, (err) => {
    if (err) throw err
    console.log('> Ready on http://localhost:3000')
  })
})

यह मुझे सर्वर की ओर से प्रमाणित अनुरोध करने की अनुमति देता है। यह मूल गोलियों में से किसी भी मुद्दे को संबोधित नहीं करता है लेकिन इसने क्लाइंट और सर्वर के बीच स्थिति साझा करने की समस्या को हल किया है।

किसी ऐसे व्यक्ति के पीओवी से जो इस सामान को बहुत कुछ सीख रहा है। मुझे लगता है कि यह सबसे अच्छा होगा यदि उदाहरण तृतीय पक्ष सेवाओं जैसे auth0 पर निर्भर नहीं हैं। नवागंतुकों के लिए लॉगिन/साइनअप फॉर्म और Redux और JWT का उपयोग करके अधिक नंगे उदाहरण देखना अधिक फायदेमंद होगा।

हम _bundle_ के लिए जिस उदाहरण की योजना बना रहे हैं, वह ओपन-सोर्स Node.js सर्वर APIs पर आधारित होगा

मैंने https://github.com/iaincollins/nextjs-starter पर एक उदाहरण स्टार्टर प्रोजेक्ट में ईमेल आधारित प्रमाणीकरण का एक उदाहरण जोड़ा है

इसमें सेशन सपोर्ट है (बैकएंड पर एक्सप्रेस सेशंस और फ्रंट एंड पर कैश करने के लिए ब्राउजर सेशनस्टोरेज एपीआई के साथ), एचटीटीपी ओनली कुकीज, सीएसआरएफ प्रोजेक्शन, ईमेल भेजने के लिए एसएमटीपी में निर्मित उपयोग, बैकएंड को बदलने में आसान है जो एसक्यूएल लाइट में डिफॉल्ट करता है . इसे चलाने के लिए किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है।

प्रोजेक्ट में लेआउट पेज, कस्टम रूट भी हैं और इसमें विकी से घड़ी का उदाहरण भी शामिल है। यह प्रमाणीकरण का सबसे प्रशंसनीय उदाहरण नहीं है, लेकिन उन लोगों के लिए मददगार हो सकता है जो सरल प्रोजेक्ट के साथ शुरुआत करना चाहते हैं जो समझने में आसान हो और इसके साथ खेलना आसान हो।

मैं @iamjacks से सहमत

मुझे त्रुटि प्रबंधन में सुधार करने और एक साधारण प्रोफ़ाइल पृष्ठ जैसी सुविधाओं को जोड़ने में प्रसन्नता हो रही है जिसे उपयोगकर्ता संपादित कर सकते हैं, और फेसबुक, Google और ट्विटर के लिए oAuth के उदाहरणों के साथ पासपोर्ट एकीकरण यदि यह लोगों के लिए उपयोगी होगा। अगर लोगों के पास घटकों के लिए सत्र जानकारी को प्रचारित/उजागर करने के बेहतर तरीकों के बारे में अच्छे विचार हैं तो मुझे बहुत दिलचस्पी है।

यह काफी अविश्वसनीय है @iaincollins। हम इसे 2.0 के रिलीज नोट्स पर निश्चित रूप से प्रदर्शित करेंगे :)

@rauchg धन्यवाद! :)

मुझे लगता है कि मुझे स्पष्ट रूप से जोड़ना चाहिए कि इस उदाहरण में सत्र क्लाइंट और सर्वर दोनों आधारित हैं - यानी जावास्क्रिप्ट के साथ और बिना काम करते हैं (और सत्र स्टोरेज के बिना सिस्टम पर), और एक ही सत्र दोनों में साझा किया जाता है।

इसे प्राप्त करने से सत्र घटक में थोड़ा सा गड़बड़ हो जाता है, जो सर्वर हेडर से सीएसआरएफ टोकन प्राप्त करने के लिए req.connection._httpMessage.locals._csrf जैसे नामों के साथ चर में जाता है - क्योंकि 'req' ऑब्जेक्ट getInitialProps() में पृष्ठों को पास किया जाता है। उत्सुकता से एक्सप्रेस में उजागर किए गए req ऑब्जेक्ट से थोड़ा अलग है क्योंकि मैं इसे सामान्य रूप से req.locals._csrf के माध्यम से एक्सेस करता हूं (हालाँकि req.session दोनों में समान है)।

लोकलस्टोरेज सुरक्षित नहीं है। इसे और अधिक सुरक्षित बनाने का सबसे अच्छा तरीका क्या है। कोई भी स्थानीय स्टोरेज डेटा चुरा सकता है और इसे फिर से अपने ब्राउज़र में डाल सकता है और पीड़ित उपयोगकर्ता के रूप में लॉग इन किया जा सकता है !!

@ चथुला यह सच नहीं है। यह तर्क गलत है।
यदि किसी के पास भौतिक रूप से ब्राउज़र तक पहुंच है, तो वे कुछ भी कर सकते हैं।

कुकीज़ के लिए भी यही सच है।

ऑथ के लिए लोकलस्टोरेज का उपयोग करना सुरक्षित है क्योंकि हम कुकी आधारित सेकेंड मुद्दों से छुटकारा पा सकते हैं।
लेकिन दूसरी ओर, यह SSR को प्रभावित करता है।

@arunoda मैंने Laravel API और Next.js क्लाइंट के साथ लॉगिन बनाया है। मैं स्थानीय स्टोरेज के अंदर authUser access_token स्टोर करता हूं। फिर प्रमाणित करके उपयोगकर्ता लॉग इन करें या नहीं जांचें। लेकिन यह सुरक्षित नहीं है। अगर किसी ने लोकलस्टोरेज डेटा चुरा लिया है। वह इसका उपयोग कर सकता/सकती है।

अगर किसी ने लोकलस्टोरेज डेटा चुरा लिया है।

कैसे? मूल रूप से उसके पास भौतिक रूप से ब्राउज़र तक पहुंच होनी चाहिए। तब वह व्यक्ति कुछ भी कर सकता था।
ऐसे में हमें इसकी चिंता नहीं करनी चाहिए।

क्या हम इसे और अधिक सुरक्षित बनाने के लिए किसी एन्क्रिप्शन का उपयोग नहीं कर सकते?

@चथुला यह विषय से हटकर है। यह Next.js के लिए बिल्कुल प्रासंगिक नहीं है और हम चाहते हैं कि वेब सामग्री सामान्य रूप से कैसे काम करती है।

@ चथुला हो सकता है कि आप उपरोक्त स्टार्टर-प्रोजेक्ट में एक नया धागा शुरू कर सकें।

@arunoda हाहा !! जानकारी के लिए धन्यवाद! :डी

@ चथुला अगर आपको विशिष्ट चिंताएं हैं तो स्टार्टर प्रोजेक्ट के मुद्दे पर मुझे और अधिक चर्चा करने में खुशी हो रही है।

लोगों को अनावश्यक रूप से चिंतित होने से बचाने के लिए, मैं किसी भी ग़लतफ़हमी को दूर करना चाहता हूँ।

वेब स्टोरेज एपीआई (यानी लोकलस्टोरेज और सेशनस्टोरेज) है - बिना httpOnly सेट के कुकीज की तरह - समान मूल नीति (प्रोटोकॉल, होस्टनाम, पोर्ट नंबर) के माध्यम से प्रतिबंधित, यह सच नहीं है कि "कोई भी [इसे] चुरा सकता है"; लेकिन हाँ यदि कोई आपके एप्लिकेशन में क्रॉस साइट स्क्रिप्टिंग भेद्यता के माध्यम से आपकी साइट पर मनमानी जावास्क्रिप्ट निष्पादित करने में सक्षम है तो वे स्टोर तक भी पहुंच सकते हैं, इसलिए आपको इसमें सत्र पहचानकर्ता स्टोर नहीं करना चाहिए।

यही कारण है कि आप देखेंगे कि सत्र टोकन स्थानीय स्टोरेज/सत्र स्टोरेज में संग्रहीत नहीं है और जावास्क्रिप्ट में पढ़ने योग्य नहीं है, यह केवल HTTP केवल कुकी के माध्यम से प्रेषित होता है (यही कारण है कि सत्र वर्ग लाने के बजाय XMLHttpRequest() का उपयोग करता है () - जैसा कि कक्षा प्रलेखन में बताया गया है)।

इसका मतलब यह है कि भले ही कोई आपके एप्लिकेशन में क्रॉस साइट स्क्रिप्टिंग भेद्यता का फायदा उठाने में सक्षम हो और आपके वेब ऐप में मनमाने ढंग से जावास्क्रिप्ट निष्पादित कर सके, फिर भी वे उपयोगकर्ता सत्र टोकन को पढ़ या निर्यात नहीं कर सकते हैं।

यह शायद प्रलेखन में श्रम करने लायक एक महत्वपूर्ण अंतर है।

नोट: उपयोगकर्ता डेटा का अतिरिक्त एन्क्रिप्शन यहां मददगार नहीं है क्योंकि ऐप को हमेशा डेटा को पढ़ने में सक्षम होना चाहिए ताकि इसे प्रस्तुत किया जा सके (इसलिए आपको ऐप में एक विवरण कुंजी भी स्टोर करने की आवश्यकता होगी, जो एन्क्रिप्टिंग प्रदान करेगी उपयोगकर्ता डेटा काफी मूट)।

_अपडेट करें: पिछले एक या दो सप्ताह में सेशनस्टोरेज पर लोकलस्टोरेज का उपयोग करने के लिए उदाहरण को फिर से तैयार किया गया था क्योंकि सेशनस्टोरेज को टैब के बीच साझा नहीं किया जाता है और गैर-सेंसिटिव डेटा साझा करने से इस तरह से अनावश्यक प्रमाणीकरण की संख्या कम हो जाती है और सत्र की स्थिति टैब के बीच सुसंगत रहती है।

हो सकता है कि कुछ लोगों के लिए उपयोगी हो, मैंने प्रयोग करते समय यह नमूना ऐप बनाया है:

https://github.com/possibilities/next.js-with-auth

इस खिलौना बैकएंड द्वारा समर्थित:

https://github.com/possibilities/micro-auth

यहां तैनात:

https://next-with-auth.now.sh/

यहां बैकएंड:

https://micro-auth.now.sh/

@ संभावनाएँ धन्यवाद माइक! साथ ही एक अलग माइक्रोसर्विस को उजागर करना जो सुरक्षित पृष्ठों को संभालने का एक अच्छा तरीका दिखाता है जो मैं सोच रहा था कि यह अच्छा प्रज्ञा हो सकता है और इससे प्रेरणा ले सकता है। मेरे पास कुछ विचार हैं जो अगले.js-with-auth रेपो में उठाए जाएंगे।

कुछ और विचार करने के बाद शायद मैं अपने प्रयासों को एक महान उदाहरण के रूप में ऊपर नहीं रखूंगा। मैं साइनअप/साइनइन पूरी तरह से वेब 1.0 शैली सबमिट करने के लिए बदल सकता हूं ताकि हम सर्वर पर केवल HTTP कुकी स्थापित कर सकें (एक्सएसएस के माध्यम से जेडब्ल्यूटी तक पहुंच को समाप्त कर सकें) और फिर उपयोगकर्ता ऑब्जेक्ट को req बजाय संलग्न करें पूरे टोकन की तुलना में। यह सीएसआरएफ कमजोरियों की संभावना को छोड़ देता है लेकिन मुझे लगता है कि यह एक्सएसएस (नहीं?) की तुलना में कम करने के लिए और अधिक सरल है। इसका एक अच्छा साइड इफेक्ट यह है कि क्लाइंट ऐप शपथ सेवा के माध्यम से साइन इन करते समय लगभग समान प्रवाह का उपयोग कर सकता है।

मैं यह भी देखता हूं कि मैं Page HoC के getInitialProps में कुकी को पार्स करके "मिडलवेयर" (और इसलिए कस्टम सर्वर की आवश्यकता) से बच सकता हूं।

@संभावनाएं चूंकि 'सीक्रेट' पेज सिर्फ एक पेज है और

हाँ, मुझे लगता है कि सर्वर-साइड रीडायरेक्ट करने के लिए वायर्ड किया जाना चाहिए।

बीटीडब्लू, मैं जीथब के साथ साइन इन करने की अपनी प्रारंभिक परियोजना में वापस विचलित हो गया। प्रवाह सुरक्षा के बारे में अधिक देखभाल के समान है (अर्थात् XSS के माध्यम से ओथ टोकन को उजागर करने से बचने के लिए क्लाइंट पर किसी भी रहस्य को उजागर नहीं करना)। यह एक उचित ऐप में बंधा हुआ है, लेकिन अगर कोई दिलचस्पी है तो मैं इसे किसी ऐसी चीज़ में तोड़ सकता हूं जो सामान्य रूप से शपथ प्रवाह के लिए उपयोगी हो सकती है।

@ संभावनाएँ मुझे लगता है कि यह एक भयानक मदद होगी, अगर कोई न्यूनतम (लेकिन उचित) उदाहरण के साथ पीआर हो सकता है मैं अपने ऐप में ऑथ पर काम कर रहा हूं (https://github.com/relatenow/ संबंधित) लेकिन यह वर्तमान में केवल क्लाइंट-साइड (लोकलस्टोरेज) है।

@sedubois मेरे पास https://github.com/zeit/next.js/pull/646 का उपयोग करने के लिए एक जनसंपर्क है, लेकिन हम कहीं और ऑथ सर्वर को स्थानांतरित करेंगे

ग्राफ़िकल का उपयोग करने के बारे में क्या?

अपोलो ग्राफ़िकल प्रमाणीकरण का एक उदाहरण देता है:

https://dev-blog.apollodata.com/a-guide-to-authentication-in-graphql-e002a4039d1

यहां हम एक ग्राफ़िकल अनुरोध को प्रमाणित कर रहे हैं, लेकिन इसे हमारे मामले के लिए अनुकूलित किया जा सकता है।

प्लस ग्राफ़िकल कार्यान्वयन और तर्क को दूर कर सकता है। इसका उपयोग पासवर्ड रहित, auth0, या किसी अन्य चीज़ के साथ किया जा सकता है जिसे हम पसंद कर सकते हैं।

@improunciable FYI आपके उदाहरण के साथ मुझे अभी तक पता नहीं है कि सत्रों को कैसे संभालना है, क्योंकि मैं पासवर्ड रहित से छुटकारा पाना चाहता हूं। मैं अपने ऐप में @iaincollins के उदाहरण को अपनाने की कोशिश

मेरी आवश्यकताएं हैं:

• सुरक्षित
• सर्वर साइड को प्रमाणित करना फिर क्लाइंट साइड
• फेसबुक और लॉगिन/पासवर्ड दोनों का समर्थन करें
• प्रामाणिक प्रदाताओं को आसानी से बदला जाना चाहिए
• ग्राफकूल में उपयोगकर्ता बनाएं
• ग्राफ़कूल के बाद के ग्राफ़क्यूएल अनुरोधों को प्रमाणित करें

मामले में यह सर्वर-साइड ऑथ के साथ मेरे ऐप में किसी की मदद करता है

• कोड https://github.com/relatenow/relate
• तैनात https://relate.now.sh

लेख को Next.js सर्वर से अलग कर दिया जाना चाहिए, लेकिन मैं इसके बारे में प्रेरणा देने के लिए किसी और की प्रतीक्षा कर रहा हूं ... साथ ही मुझे यकीन नहीं है कि यह सीएसआरएफ के खिलाफ ठीक से सुरक्षित है या नहीं।

यह जो मैंने किया है:

• जब उपयोगकर्ता लॉग इन करता है, क्लाइंट-साइड जावास्क्रिप्ट ब्राउज़र में एक कुकी सेट करता है जिसमें प्रमाणीकरण वाहक टोकन होता है
• प्रमाणित अनुरोध करते समय सर्वर-साइड (नेक्स्ट.जेएस) कोड ब्राउज़र के अनुरोध के हेडर में बियरर टोकन को पढ़ता है और क्लाइंट की ओर से एपीआई सर्वर से संपर्क करने के लिए इसका उपयोग करता है।

यह एक्सएसएस के लिए कमजोर है (भले ही प्रतिक्रिया इसे रोकने के लिए बहुत कुछ करती है) और सीएसआरएफ हमले लेकिन यह आसान है और एसएसआर के साथ काम करता है।

बस अनुरोधों में जोड़ने के लिए

graph.cool + apollo + jwt + auth0 + next.js, इसके पहले 4 भाग पहले से ही https://github.com/graphcool-examples/react-apollo-auth0-example पर किए जा चुके हैं।

@balupton आपके उदाहरण में क्या होता है जब उपयोगकर्ता अभी भी कनेक्ट होने पर टोकन समाप्त हो जाता है, क्या सत्र अभी खत्म हो गया है या इसे किसी भी तरह नवीनीकृत किया गया है?

@nmaro नहीं जानता, मेरे द्वारा नहीं लिखा गया - वहाँ पर पूछने के लिए सबसे अच्छा है

मेरे अपने ऐप के लिए, मुझे अगला.js और auth0 के साथ auth जा रहा है, फिर एक zeit/micro API सर्वर के साथ जो वाहक टोकन की पुष्टि करता है।

फरवरी में कभी-कभी ओपन-सोर्स करने में सक्षम होना चाहिए।

उसी दर्शन का पालन करते हुए कि next.js अनुसरण कर रहा है (एक काम करें और इसे अच्छी तरह से करें), मैंने नोड के लिए एक एक्स्टेंसिबल यूजर अकाउंट सिस्टम का कंकाल विकसित किया है। यहां दर्शन देखें: https://medium.com/the-ideal-system/ooth-user-accounts-for-node-js-93cfcd28ed1a#.97kyfg4xg

जीथब परियोजना यहाँ है: https://github.com/nmaro/ooth/

लक्ष्य एक एक्स्टेंसिबल, स्वतंत्र प्रमाणीकरण + उपयोगकर्ता प्रबंधन सेवा है जो एक अलग माइक्रोसर्विस के रूप में उपयोग करने के लिए आदर्श है, एक एप्लिकेशन संरचना जो नोड.जेएस के साथ बहुत अच्छी तरह से खेलेगी।

ईमेल+पासवर्ड प्रमाणीकरण के साथ एक उदाहरण यहाँ है: https://github.com/nmaro/ooth/tree/master/examples/ooth
फेसबुक और गूगल ऑथ (ओथ-फेसबुक, और ओथ-गूगल) के लिए पहले से ही पैकेज मौजूद हैं, जिन्हें क्रमशः पासपोर्ट-फेसबुक और पासपोर्ट-गूगल के आधार पर लागू करना आसान होना चाहिए।

मैं एक अगला.जेएस एकीकरण उदाहरण यथाशीघ्र पोस्ट करूंगा। बेझिझक चर्चा में शामिल हों और योगदान दें।

प्लग के लिए खेद है, लेकिन यह अधिक अच्छे के लिए है - मुझे सच में विश्वास है कि अभी तक नोड के लिए कोई अच्छा समाधान नहीं है, और यह सिर्फ उन लोगों का सही दर्शक है जो ऐसी चीज चाहते हैं। शांति

इस बीच... यहां एक उदाहरण ग्राफ़िकल एपीआई है जिसे केवल लिखने के संचालन के लिए जेडब्ल्यूटी-टोकन के साथ प्रमाणीकरण की आवश्यकता है। अपनी पसंदीदा प्रमाणीकरण विधि के साथ इसका उपयोग करने के लिए स्वतंत्र महसूस करें :)

https://github.com/nmaro/ooth/tree/master/examples/graphql-api-with-auth

मैंने oAuth समर्थन जोड़ने के लिए https://nextjs-starter.now.sh अपडेट किया है।

• यह एक्सप्रेस-सत्रों (पहले की तरह) के साथ, oAuth के लिए पासपोर्ट का उपयोग करता है।
• Facebook, Google और Twitter+ oAuth के लिए समर्थन उपलब्ध है और अधिक जोड़ना आसान है (देखें AUTHENTICATION.md और मार्ग/auth-passport.js )।
• यह ईमेल साइन इन के रूप में यूनिवर्सल क्लाइंट/सर्वर सेशन सिस्टम (CSRF टोकन के साथ, केवल HTTP कुकीज़ के माध्यम से XSS सुरक्षा, Mongo, SQL DBs, Redshift, आदि का समर्थन करने वाली ORM परत) का उपयोग करता है।
• रिपोर्ट कर सकते हैं कि डेवलपर पोर्टल पर oAuth को कॉन्फ़िगर करने का अनुभव हमेशा की तरह भयानक है (अजीब त्रुटियां होती हैं और इसे डीबग करना कठिन होता है)।

ओएथ की प्रकृति - डीबी + सत्र + पासपोर्ट और त्रुटि प्रबंधन के लिए एक साथ मिलकर काम करने की आवश्यकता है - और सत्रों में क्लाइंट और सर्वर दोनों को काम करने की आवश्यकता होती है और यह कैसे सार्वभौमिक प्रतिपादन के साथ काम करता है - इसका मतलब है कि एक बार में कोशिश करने और लपेटने के लिए थोड़ा सा आप यह पता लगाने की कोशिश कर रहे हैं कि क्या हो रहा है, लेकिन क्लाइंट लॉजिक में कोई oAuth विशिष्ट कॉन्फ़िगरेशन नहीं है, इसलिए यह बहुत गन्दा नहीं है।

मुझे केवल प्रमाणीकरण को एक अलग उदाहरण में विभाजित करने में खुशी होगी, हालांकि मुझे संदेह है कि यह बहुत छोटा नहीं होगा। कोई और चाहे तो बढ़िया। मैं शायद किसी बिंदु पर उदाहरण में थोड़ा और जोड़ दूंगा (जैसे खाता प्रबंधन पृष्ठ)। शायद दस्तावेज़ीकरण से अधिक लिंक करना अच्छा होगा।

अद्भुत कार्य! यदि आप लेख को विभाजित कर सकते हैं और इसे अगले.जेएस रेपो में जोड़ सकते हैं जो बहुत बढ़िया होगा: दिल:

मैं इसे बीटीडब्ल्यू भी कर सकता हूं

मेरे पास अगले 2 हफ्तों में समय नहीं होगा, इसलिए यदि कोई ऐसा करना चाहता है तो यह बहुत अच्छा होगा।

मुझे इसे रिफैक्टर करना अच्छा लगेगा और देखें कि क्या इसे केवल एक मॉड्यूल तक कम किया जा सकता है (जो लॉगिन बटन जैसे सरल घटकों को उजागर करता है और एम्बेड करने के लिए फॉर्म में साइन इन करता है), और वास्तव में पहले के क्लाइंट-साइड-ओनली उदाहरण से कुछ प्रेरणा लेने के लिए @improunciable द्वारा।

अपडेट: मैं वास्तव में दूर जा रहा हूं, इसलिए मैं नहीं जा सकता, लेकिन जब मैं वापस आता हूं तो मुझे ऐसा करने में खुशी होती है!

मैंने कुछ संशोधन के साथ auth0/react क्विक स्टार्ट गाइड का पालन किया है, लेकिन जब मैं lock.show() कॉल करता हूं, तो ऐप शिकायत करता है:

ध्यान में न आया त्रुटि: addComponentAsRefTo(...): केवल एक ReactOwner refs हो सकता है। हो सकता है कि आप किसी ऐसे घटक में रेफरी जोड़ रहे हों जो किसी घटक के render पद्धति के अंदर नहीं बनाया गया था, या आपके पास रिएक्ट लोड की कई प्रतियां हैं

@iaincollins @timneutkens आपके उदाहरण के बारे में, अगर मैं गलत हूं तो कृपया मुझे सही करें।

उदाहरण सत्र टोकन को संग्रहीत करने के लिए httpOnly कुकी का उपयोग करता है जो इसे जावास्क्रिप्ट इंजेक्शन हमलों (XSS) के विरुद्ध सुरक्षित बनाता है। फिर यह सीएसआरएफ हमलों से बचाने के लिए स्थानीय भंडारण में संग्रहीत सीएसआरएफ टोकन रखने की समस्या में चला जाता है।

एक अंतर्निहित धारणा है कि तकनीकों का यह संयोजन चीजों को सुरक्षित बनाता है, जो उपयोगकर्ता/डेवलपर को गुमराह कर सकता है। एक हमलावर अभी भी पृष्ठ (XSS) में जावास्क्रिप्ट को इंजेक्षन कर सकता है, सीएसआरएफ टोकन पढ़ सकता है, और एपीआई को प्रमाणित (कुकी) अनुरोध करने के लिए इसका उपयोग कर सकता है। क्या रीडमी में उल्लेख करने योग्य है?

नमस्ते @davibe

काश, वर्तमान में एक सत्र कुकी और एक अलग घूर्णन सीएसआरएफ टोकन की तुलना में तकनीकी रूप से बेहतर दृष्टिकोण नहीं है, इसलिए मुझे लगता है कि मुझे यह कहना होगा कि मैं मॉडल से काफी खुश हूं क्योंकि ऐसा करने का कोई दूसरा तरीका नहीं है। (भले ही वास्तविक कार्यान्वयन में हमेशा सुधार किया जा सके)।

हम ब्राउज़र फिंगर प्रिंटिंग जोड़ सकते हैं, शायद सत्र टोकन अधिक बार घूम सकता है (मैं भूल जाता हूं कि यह अभी स्वचालित है), सीएसआरएफ टोकन परम के बजाय हेडर हो सकता है, कुकीज़ वास्तव में केवल उत्पादन में एसएसएल होनी चाहिए और हम जोड़ सकते हैं टोकन में साइन इन करने के लिए एक समाप्ति तिथि, लेकिन AFAICS में सुधार के लिए काफी सीमित गुंजाइश है जहां तक ​​सुरक्षा मॉडल जाता है और ऐसा कुछ भी नहीं है जो वास्तव में किसी ऐप में किसी भी कोड को इंजेक्ट करने में सक्षम होने की स्थिति में और सुरक्षा प्रदान करता है; लेकिन कृपया बेझिझक उन चीजों को रेपो में सुधार के मुद्दों के रूप में उठाएं।

यदि कोई खाता स्थिति संशोधित करने के विकल्प थे (जो वर्तमान में नहीं हैं) तो हम उन्हें बिना अनुमति के सर्वर पर परिवर्तन करना अधिक कठिन बनाने के लिए उन्हें करने से पहले एक कैप्चा प्राप्त कर सकते हैं, लेकिन उदाहरण में जो कुछ होता है वह यह है कि उपयोगकर्ता साइन इन कर सकते हैं और बाहर इसलिए कि वर्तमान में दायरे से बाहर है।

सत्र टोकन का भंडारण स्थानीय भंडारण इसे विशेष रूप से कम सुरक्षित बना देगा और कल्पना में इच्छित उपयोग के खिलाफ जाएगा, इसलिए व्यक्तिगत रूप से मैं इसके पक्ष में नहीं हूं - हालांकि मैं सराहना करता हूं कि यह चीजों को सरल करेगा, क्योंकि सीएसआरएफ प्रक्षेपण नहीं है, लेकिन लोग शायद इसके उदाहरण की आवश्यकता नहीं है क्योंकि यह करना बहुत आसान होगा - मैंने केवल एक प्रदान करने का प्रयास किया है क्योंकि यह बहुत अजीब है। :-)

मैं पूरी तरह से आपके साथ हूं कि मुझे भी नफरत है कि यह कितना अजीब है और इसे एक मॉड्यूल में बदलने की कोशिश नहीं की है।

हम्म .. मैं समझता हूँ।
यह मुद्दा मेरे लिए बहुत उपयोगी था, धन्यवाद।

यह Auth0 का दृष्टिकोण है https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
वे मूल रूप से कुकीज़ से बचने का सुझाव देते हैं लेकिन मुझे लगता है कि पहले पृष्ठ लोड पर एसएसआर छोड़ देगा।

ज़रा सुनिए सभी!

मैं next.js के साथ प्रमाणीकरण पर भी काम कर रहा हूं और इस मुद्दे से टिप्पणियां, विशेष रूप से @davibe + रेपो और पीआर से काफी मदद मिली है।

मेरा समाधान निम्नलिखित करता है:

• सफल लॉगिन पर, मेरा रेडक्स रेड्यूसर प्रतिक्रिया-कुकी का उपयोग करके कुकी में टोकन और उपयोगकर्ता डेटा सहेजता है।
• कोई भी पृष्ठ / घटक जिसे उस जानकारी की आवश्यकता होती है, उसे @timneutkens with-session.js के समान उच्च-क्रम वाले घटक में लपेटा जाता है। यदि SSR, टोकन ctx.req.headers.cookie में उपलब्ध होगा, अन्यथा इसे केवल ब्राउज़र दस्तावेज़ से प्राप्त करें (प्रतिक्रिया-कुकी लोड विधि का उपयोग करें)।
• एक बार मेरे पास टोकन हो जाने के बाद, जब भी मैं अनुरोध करता हूं, मैं इसे वाहक/प्राधिकरण शीर्षलेख में सेट कर सकता हूं।

यह मदद करता है कि मेरे पास एक डॉकटर कंटेनर में अपना स्वयं का जेडब्ल्यूटी टोकन प्रमाणीकरण माइक्रोसर्विस चल रहा है।
शायद प्रमाणीकरण के साथ उदाहरण के हिस्से के रूप में एक साधारण जेडब्ल्यूटी सेवा प्रदान करना आसान होगा? इस प्रकार server.js को हैक करने से बचना और संभावित रूप से next.js बेक-इन हॉट रीलोडिंग, ssr और रूटिंग के लाभों को खोना?

मुझे यह भी यकीन नहीं है कि सीएसआरएफ/एक्सएसएस के मामले में यह दृष्टिकोण सुरक्षित है या नहीं। किसी भी टिप्पणी का स्वागत है।

आपने अब तक जो अद्भुत काम किया है, उसके लिए आप सभी का धन्यवाद। मैं इस परियोजना का बहुत बड़ा प्रशंसक हूँ!

@jcsmesquita मैं उदाहरण के एक नए संस्करण पर काम कर रहा हूं जिसमें सब कुछ Next.js से अलग है जैसे कि zeit.co पर कैसे लागू किया जाता है।

यह उपयोगी प्रतीत होता है: https://hub.docker.com/r/rabbotio/nap/~/dockerfile/

@subsumo उल्लेख के लिए धन्यवाद, एनएपी मेरा है, वेब के माध्यम से ऑथन @iaincollins nextjs-starter पर आधारित है और टोकन के साथ मूल क्लाइंट लॉगिन पर प्रतिक्रिया करता है।

@timneutkens जिस समाधान पर आप काम कर रहे हैं वह आपको एक अलग सेवा की ओर प्रमाणित करने की अनुमति देता है?

मैं वर्तमान लेख उदाहरण पुल अनुरोध देख रहा हूँ https://github.com/zeit/next.js/pull/1141
मुझे ऐसा लगता है कि यह केवल अगले.जेएस सर्वर की ओर प्रमाणित करने की अनुमति देता है, लेकिन आइसोमोर्फिक रूप से एक अलग सेवा की ओर नहीं।

दूसरे शब्दों में, मान लें कि आप अगला.जेएस सर्वर और वास्तविक ऐप एपीआई (जैसे आरईएसटी या ग्राफक्यूएल) को अलग करना चाहते हैं, तो आप जो करना चाहते हैं वह यह है कि क्लाइंट और सर्वर एपीआई की ओर प्रमाणित करने में सक्षम हैं। मुझे नहीं लगता कि यह समाधान वास्तव में आपकी मदद करता है।

मैंने एक प्रवाह के बारे में सोचा।

संस्थाएं:

• ग्राहक (सी)
• Next.js सर्वर (एस)
• एपीआई (ए)

लक्ष्य 3 कुकी-आधारित सत्र स्थापित करना है:

1. सीएस
2. सीए
3. एसए

सत्र 1) इसलिए है कि क्लाइंट सर्वर को पहचानता है, और 2) 3) ऐसा है कि क्लाइंट और सर्वर दोनों स्वतंत्र रूप से एपीआई तक पहुंचने के लिए अपने संबंधित सत्रों का उपयोग कर सकते हैं।

यह प्रवाह है:

1. सीएस आसानी से किया जाता है, किसी प्रमाणीकरण की आवश्यकता नहीं है
2. सीए प्रमाणीकरण के साथ किया जाता है (उदाहरण के लिए उपयोगकर्ता नाम/पासवर्ड के साथ)। इसके अतिरिक्त, एक JWT प्रदान किया जाता है
3. क्लाइंट सर्वर को JWT प्रदान करता है और फिर उसे छोड़ देता है
4. SA JWT के साथ किया जाता है, जिसे बाद में छोड़ दिया जाता है

क्या आपकी राय? क्या कोई आसान तरीका है? क्या हमें इसके बजाय केवल API को next.js सर्वर के साथ युग्मित रखना चाहिए, ताकि केवल एक सत्र (CS) की आवश्यकता हो?

@rauchg मैं आपको आसानी से नहीं बुलाता, लेकिन मेरा मानना ​​​​है कि यह इस बारे में भी है कि आगे किस दिशा में जाना है। जेएस को जाना है - "सार्वभौमिक फ्रंट-एंड" के रूप में इसे डेटा प्रदान करने वाले एपीआई से अलग से चलाना चाहिए? यदि हाँ, तो हमें यह अधिकार प्राप्त करने की आवश्यकता है।

@timneutkens जिस समाधान पर आप काम कर रहे हैं वह आपको एक अलग सेवा की ओर प्रमाणित करने की अनुमति देता है?

यही विचार है हाँ। Next.js पर अन्य चीजों को ठीक करने में व्यस्त हैं। इसे ASAP वापस मिल जाएगा।

मैंने अपने ऐप के जीथब-ऑथ-विशिष्ट भागों को एक सुंदर सुपाच्य उदाहरण में तोड़ दिया। कुछ के लिए दिलचस्प हो सकता है और कोड या प्रवाह पर कोई प्रतिक्रिया पसंद करेंगे: https://github.com/possibilities/next-github-auth-example

अद्यतन: मैंने उदाहरण ऐप को घटकों के पुन: प्रयोज्य सेट में दोबारा प्रतिक्रिया दी जिसे अगले ऐप्स में "गिराया" जा सकता है

अनुवर्ती: मैंने ओथ और एक ग्राफक्यूएल एपीआई के साथ एकीकरण लिखा था।

https://medium.com/the-ideal-system/ooth-user-accounts-for-node-js-93cfcd28ed1a#.ykoj1dhil

यह मौजूदा दृष्टिकोणों पर आधारित है, यानी अगले.जेएस सर्वर की ओर प्रमाणीकरण, यानी यह एपीआई और प्रमाणीकरण सर्वर को एक ही प्रक्रिया में चलाने के लिए मानता है, इसलिए केवल एक सत्र बनाना होगा। लाभ: सैद्धांतिक रूप से यह किसी भी पासपोर्ट.जेएस रणनीति के लिए / के लिए क्रेडेंशियल स्टोर कर सकता है।

@timneutkens ने उस मोर्चे पर कोई प्रगति की है?

मैंने अपने जीथब ऑथ उदाहरण ऐप को अगले ऐप्स में "गिथब ऑथ को छोड़ने" के लिए सजावटी और पेज घटक के पुन: प्रयोज्य सेट में दोबारा प्रतिक्रिया दी। कोड और कार्यक्षमता प्रतिक्रिया का स्वागत किया। https://github.com/possibilities/next-github-auth

मैं _थिंक_ यहां बोर्डों को नीचे करना दिलचस्प हो सकता है और फिर इसे अगले के लिए एक अधिक सामान्य लेख ढांचे में विकसित करना जारी रख सकता है।

@timneutkens
आपको पिंग करने के लिए खेद है, लेकिन क्या आपने इस पर कोई प्रगति की है? मैं पूरी तरह से खो गया हूं कि मुझे next.js के साथ प्रमाणीकरण कैसे ठीक से सेट करना चाहिए।

@kolpav मैंने इस पर कुछ काम किया है, वर्तमान में अन्य सामानों से भरा हुआ है हर तरह से यह अगली के लिए मेरी प्राथमिकताओं की सूची में बहुत अधिक है

एक नेक्स्ट.जेएस ऐप के साथ प्रमाणीकरण प्राप्त करने का एक स्पष्ट, अच्छी तरह से प्रलेखित और सुरक्षित तरीका फ्रेमवर्क के रूप में इसकी सफलता के लिए महत्वपूर्ण है।

मुझे याद नहीं आ रहा है कि पिछली बार मैंने कब ऐसा वेब बनाया था जिसमें प्रमाणीकरण नहीं था।
ज्यादातर लोगों की तरह मैं भी कल्पना करता हूं, मैं भी अपने समर्थित डेटा के लिए सुरक्षित कॉल करना चाहता हूं, इसलिए जेडब्ल्यूटी स्पष्ट समाधान प्रतीत होता है।

लेकिन मुद्दों और जनसंपर्क के बीच इतनी चर्चा है कि मुझे यकीन नहीं है कि कहां से शुरू किया जाए!

@timneutkens
कूल मुझे लगता है कि यह दूसरों के लिए बहुत मूल्यवान होगा।

@camstuart @kolpav ऊपर कुछ अच्छे, काम करने वाले उदाहरण हैं जिनमें ओएथ और ईमेल आधारित प्रमाणीकरण शामिल हैं जो योगदानकर्ताओं @jaredpalmer , @luisrudge , @improunciable , @possibilities और स्वयं द्वारा JWT और HTTP दोनों कुकीज़ का उपयोग करते हैं।

कुछ लिंक को हाइलाइट करने के लिए चेक आउट करें:

• https://nextjs-auth0.now.sh
• https://nextjs-starter.now.sh
• https://github.com/possibilities/next-github-auth

(सूक्ष्म लेख उदाहरण अच्छा था लेकिन मुझे लगता है कि इसे अद्यतन करने की आवश्यकता है।)

आगे सुधार की गुंजाइश है, जिस पर अतिरिक्त टिप्पणीकारों ने ऊपर टिप्पणी की है - जिसमें सत्र स्टोर घटक और सर्वर तर्क को विभाजित करना शामिल है; और एक उदाहरण जो चीजों को और भी सरल बनाता है जिस पर टिम काम कर रहा है।

सामान्यता के लिए सरलता यूनिवर्सल ऐप्स के लिए एक चुनौतीपूर्ण क्षेत्र है, लेकिन आपको उपरोक्त उदाहरणों को प्राप्त करने में सक्षम होना चाहिए - या सीधे डेमो आज़माएं - और देखें कि वे बिना किसी परेशानी के कैसे काम करते हैं।

@iaincollins यह बहुत अच्छा उदाहरण है। लेकिन मैं कैसे (उदाहरण के लिए) स्टार्टर प्रोजेक्ट का उपयोग कर सकता हूं? तो अगर मैं अपना ऐप बनाना चाहता हूं। मुझे इस रेपो को क्लोन करने की ज़रूरत है? या मुझे स्टार्टर प्रोजेक्ट खंड से अपने कोड में "कॉपी-पेस्ट" कोड की आवश्यकता है?

अगर स्टार्टर प्रोजेक्ट को अपडेट किया जाएगा - मुझे क्या करना चाहिए?

@iaincollins
अच्छे उदाहरण विशेष रूप से आपके।
लेकिन फिर भी, मैं उस पर अनुमोदन की ज़ीट मुहर के साथ प्रामाणिक उदाहरण देखना चाहता हूं - सभी आंखें एक दिशा में इंगित करेंगी ताकि कोई त्रुटि या गलती किसी का ध्यान न जाए। अभी के लिए, मेरे पास अपना काम करने का अधिकार है लेकिन मुझे यकीन नहीं है कि यह कितना सुरक्षित है।

सहमत @kolpav , अपनी खुद की सुरक्षा रोल करना एक मुश्किल काम है। विशेषज्ञों के लिए सबसे अच्छा छोड़ दिया

मैंने इसके लिए एक स्टैक बनाया है जो ग्राफ़क्यूएल के साथ प्रमाणीकरण को आसानी से संभाल सकता है: https://github.com/thebillkidy/MERGE-Stack

@salmazov मुझे आरंभ करने और समझने का एक उपयोगी तरीका मिल गया है कि एक उदाहरण या स्टार्टर प्रोजेक्ट में क्या हो रहा है, इसे फोर्क करना हो सकता है, फिर उन चीजों को हटा दें जो प्रासंगिक नहीं हैं जब तक कि आप केवल कार्यक्षमता से संबंधित कोड के साथ नहीं छोड़े जाते आप लागू करना चाहते हैं; और फिर उस कार्यक्षमता को किसी अन्य प्रोजेक्ट पर पोर्ट करने का प्रयास करने के लिए।

@kolpav @camstuart इस धागे में विभिन्न सुरक्षा मॉडलों की वास्तव में व्यापक चर्चा है, जिसमें कुछ सामान्य गलतफहमियों और व्यापार-नापसंद को दूर करना शामिल है। मैं विशेष रूप से केवल HTTP कुकीज़ और सीएसआरएफ टोकन (और सत्र टोकन के लिए जेडब्ल्यूटी और/या वेब स्टोरेज एपीआई का उपयोग करने पर एक्सएसएस और सीएसआरएफ के खिलाफ अतिरिक्त सुरक्षा देता हूं) के बारे में बिंदुओं को नोट करता हूं। यह वास्तव में पढ़ने लायक है।

@iaincollins क्या आपका मतलब कुछ लिंक करना था? :मुस्कुराओ:

हैलो दोस्तों :)

मेरे पास एक सवाल है, मैं आगे पढ़ रहा था, स्थानीय स्टोरेज से jwt के साथ ऑथ के लिए टोकन नहीं मिल सकता।

अगर मेरे पास अगली के साथ मेरी साइट का पहला चार्ज प्रस्तुत करने के लिए सर्वर है। और मेरे पास मेरे एपीआई के लिए एक और सर्वर है। यह ग्राहक से उपयोगकर्ता/पास प्राप्त करता है और एक jwt देता है। किन मामलों में मुझे सर्वर में टोकन प्राप्त करने की आवश्यकता है ??

मुझे रेंडर सर्वर (अगले) में टोकन की आवश्यकता क्यों होगी?

यदि क्लाइंट एपीआई सर्वर को टोकन नहीं भेजता है, तो एपीआई डेटा नहीं देता है, और उपयोगकर्ता को निजी जानकारी नहीं मिल सकती है। मुझे समझ में नहीं आ रहा है कि मुझे रेंडर सर्वर पर टोकन भेजने की आवश्यकता क्यों है।

@ kamilml

यह मदद कर सकता है। सामान्य तौर पर, आपके पास दो विकल्प होते हैं:

1. अगला सर्वर जेडब्ल्यूटी दें (संभवतः कुकी के माध्यम से)। यह नेक्स्ट सर्वर को क्लाइंट की ओर से एपीआई कॉल करने की अनुमति देगा। आप इसे चाहते हैं यदि पूर्ण सर्वर साइड प्रतिपादन आपके लिए महत्वपूर्ण है।

2. क्लाइंट स्थानीय स्टोरेज में जेडब्ल्यूटी स्टोर करें और नेक्स्ट सर्वर को इसे एक्सेस न दें। इस मामले में, आप बस एपीआई कॉल सर्वर साइड को बायपास कर सकते हैं और क्लाइंट साइड लोडिंग पूर्ण होने तक पूर्ण रेंडर स्थगित कर सकते हैं।

इसे फिर से खोलने के लिए खेद है, लेकिन मैंने सोचा कि मैं इस धागे में अपने 2 सेंट जोड़ दूंगा, और इस क्षेत्र में मेरा प्रारंभिक आर एंड डी कैसे बढ़ रहा है। कम कोड उदाहरण, अधिक उच्च-स्तरीय प्रवाह।

सबसे पहले, संदर्भ के लिए, हमारा अधिकांश ऐप पहले से ही सिम्फनी 3 (PHP) में बनाया गया है, और हाइब्रिड अनुभव के लिए Vue का उपयोग करता है। सर्वर एक रैपर पृष्ठ प्रस्तुत करता है, और ऐप डेटा को ऐप को लेने के लिए __INITIAL_STATE__ असाइन करता है। इसके परिणामस्वरूप सिम्फनी (एसईओ के लिए) में मार्केटिंग पेजों को प्रस्तुत करने और जेएस के माध्यम से डेटा प्राप्त करने और अधिक एसपीए-ईश अनुभव प्रदान करके अन्य क्षेत्रों में एसईओ पर यूएक्स/यूआई चुनने के बीच निर्णय लिया गया है। यह भी ध्यान देने योग्य है, सभी पृष्ठ बाइनरी सार्वजनिक/निजी नहीं हैं (जैसा कि मैंने कुछ उदाहरणों में देखा है)। कुछ पृष्ठ डिफ़ॉल्ट रूप से सार्वजनिक होते हैं, और फिर प्रमाणित होने पर अलग तरीके से प्रस्तुत होते हैं। हम साइट के कुछ हिस्सों के लिए एक एसपीए का उपयोग करने पर विचार कर रहे थे, लेकिन कई व्यावहारिक तरीकों से, यह एक खराब यूएक्स/यूआई (धीमा टीटीआई, प्रगति बार, आदि) था। इसके अलावा, यह एसईओ समस्या को हल नहीं करता है, जब तक कि हम एफओयूसी पेश नहीं करते हैं और दो बार पाठ प्रस्तुत करते हैं (एक बार सिम्फनी के माध्यम से, एक बार फिर जेएस घटकों के रूप में), आदि।

एसएसआर / यूनिवर्सल जेएस दर्ज करें ...

मेरे मामले में, मैंने जो किया, वह PHPSESSID तर्क की नकल करना था, एक HttpOnly UJSSESSID कुकी बनाकर (नाम बनाया), और उपयोगकर्ता के लिए मान सेट किया जेडब्ल्यूटी। सिम्फनी ऐप प्रत्येक पृष्ठ अनुरोध में इसे पास करता है क्योंकि उपयोगकर्ता साइट के चारों ओर नेविगेट करता है। जब उपयोगकर्ता यूजेएस पृष्ठों को हिट करता है, तो उन ऐप्स के सर्वर-साइड अनुरोध में कुकीज़ प्राप्त करेंगे (ब्राउज़र के अंतर्निहित व्यवहार के अनुसार)। यदि UJSSESSID कुकी सेट की जाती है, तो ऐप उपयोगकर्ता की जानकारी प्राप्त करने के लिए एपीआई को कॉल करता है (उदाहरण के लिए /api/v1/users/me Authentication हेडर के माध्यम से टोकन पास करने के साथ)। बाकी कॉलें उसी टोकन का उपयोग करके एपीआई के माध्यम से की जाती हैं। सिम्फनी लॉगआउट तंत्र UJSSESSID कुकी को साफ करता है। अगली बार UJS ऐप लोड होने पर, यह अनाम उपयोगकर्ता मोड में पृष्ठों को प्रस्तुत करेगा। एफवाईआई, सिम्फनी बनाम यूजेएस पेज रूटिंग अपाचे के ProxyPass माध्यम से किया जाता है। स्थानीय स्टोरेज का उपयोग नहीं किया जाता है।

अंतिम परिणाम एक निर्बाध यूएक्स है जहां उपयोगकर्ता कुछ पृष्ठों पर है जो क्लाइंट-साइड जेएस के साथ PHP हैं, और कुछ पेज यूजेएस हैं। यह हमें ए / बी परीक्षण करने में सक्षम बनाता है, और साइट को बार-बार अपडेट करता है - हर किसी को खरोंच से शुरू नहीं करना पड़ता है :)

जबकि यह सहजीवी PHP/UJS के कारण थोड़ा अधिक जटिल है, उसी सिद्धांत का उपयोग API या Node.js सर्वर मिडलवेयर (जैसे एक्सप्रेस, एडोनिस, आदि) के साथ पूर्ण UJS समाधान में किया जा सकता है। PHP पृष्ठ अनुरोध ( HttpOnly ध्वज) के माध्यम से UJSSESSID कुकी सेट करने के बजाय, उपयोगकर्ता को अपने एसपीए/यूजेएस के माध्यम से लॉगिन करें, और वहां कुकी सेट करें। आपको क्या नहीं करना चाहिए, JWT को डीकोड करने के लिए अपने ऐप का उपयोग करना है, या तृतीय पक्ष कॉल करना है जिसके लिए client_secret आवश्यकता होती है। उसके लिए सर्वर पर रहने वाले मिडलवेयर का इस्तेमाल करें।

आशा है कि यह किसी की मदद करता है। मैंने जो अन्य उदाहरण देखे हैं, वे मेरे लिए थोड़े बहुत पेट्री डिश थे।

@jaredpalmer अरे उस कार्यान्वयन के लिए धन्यवाद, मैंने इसे करने की कोशिश की, बस अपने सभी कोड को कॉपी-पेस्ट किया और अपने डैशबोर्ड.जेएस को मेरे इंडेक्स.जेएस से बदल दिया जो इस तरह दिखता है:

const index = () =>
  <div>
    <span>WoooHoooo</span>
  </div>

export default withAuth(index)

और साथ में मैंने इसे साइनइन पेज पर रीडायरेक्ट करने के लिए बदल दिया।
लेकिन इससे पहले कि यह साइन इन पेज पर रीडायरेक्ट करता है, इंडेक्स पेज की सामग्री अभी भी थोड़ी देर के लिए फ्लैश होती है। :एस

इस मुद्दे की स्थिति क्या है? मैं

पूरी चर्चा को पढ़ने वाले नए लोगों के लिए यह थोड़ा भारी है। मैंने यहां बहुत ही बुनियादी प्रमाणीकरण को लागू करने का निर्णय लिया। केवल 2 पृष्ठ (सूचकांक, लॉगिन), और एक कस्टम सर्वर
https://github.com/trandainhan/next.js-example-authentication-with-jwt

मूल रूप से, हमारे पास प्रत्येक अनुरोध के शीर्षलेख में टोकन की जांच करने के लिए सर्वर में प्रमाणीकरण मिडलवेयर है। jwt-token कुकीज़ में स्टोर किया जाएगा। मुझे लगता है कि यह बहुत आसान है, सीधे आगे है और बहुत अच्छी तरह से काम करता है।

@trandainhan क्या आप एक पोस्ट एंडपॉइंट जोड़ सकते हैं जो

@sbking सीएसआरएफ हमलों द्वारा संरक्षित एक उदाहरण समापन बिंदु के साथ अद्यतन स्रोत कोड

क्या यह का उपयोग करने के लिए तैयार है?

किसी ने redux-auth-आवरण के साथ प्रमाणन की कोशिश की?

सभी को नमस्कार! पिछले महीनों में मैंने बनाया, और अब परिष्कृत किया गया

• नोड.जेएस के लिए एक सामान्य उपयोगकर्ता खाता पुस्तकालय जिसे ओथ कहा जाता है: https://github.com/nmaro/ooth
• एक न्यूनतम बॉयलरप्लेट के साथ अगले और ऊथ पर आधारित एक स्टार्टर लाइब्रेरी: https://github.com/nmaro/staart

इसकी विशेषताएं:

• ईमेल और पासवर्ड के साथ पंजीकरण
• ईमेल या उपयोगकर्ता नाम और पासवर्ड के साथ लॉगिन करें
• खाता पृष्ठ जहां आप अपना उपयोगकर्ता नाम सेट कर सकते हैं, अपना पासवर्ड बदल सकते हैं, और एक सत्यापन ईमेल भेज सकते हैं
• पासवर्ड भूल गए/पासवर्ड पृष्ठ रीसेट करें
• ईमेल पेज सत्यापित करें
• मोंगोडीबी से जुड़ा एक बुनियादी ग्राफक्यूएल एपीआई (1 फ़ाइल, आसानी से हटाया जा सकता है)
• न्यूनतम बॉयलरप्लेट (जितना संभव हो उतना तर्क पुस्तकालयों में समझाया गया है)

यहां लाइव डेमो देखें :

मैंने इसे मुख्य रूप से अपने लिए रैपिड प्रोटोटाइपिंग के लिए किया था, एक सरल, कार्यशील खाता प्रणाली के साथ एक एप्लिकेशन के साथ जल्दी से आरंभ करने के लिए जो बाहरी सेवाओं पर निर्भर नहीं करता है। मैं परिणामों से काफी खुश हूं। मैं इन पुस्तकालयों का उपयोग और रखरखाव करना चाहता हूं, इसलिए यदि आपको लगता है कि एक स्थापित खाता प्रणाली + नोड के लिए यूआई अभी भी गायब है तो इसे आज़माएं।

@trandainhan धन्यवाद, यह वास्तव में बहुत अच्छा उदाहरण है और बहुत से लोगों के लिए बहुत आसान है और कई परिदृश्यों में काम करेगा।

मैं इस बारे में सोचने जा रहा हूं कि मैं नेक्स्टज-स्टार्टर में वर्तमान तर्क को इसके बजाय कुछ इस तरह से उपयोग करने के लिए कैसे अनुकूलित कर सकता हूं, लेकिन सुरक्षित रूप से, जबकि वास्तविक दुनिया के उपयोग के मामलों के लिए एक्सप्रेस-सत्र तर्क के साथ संगत होने के बावजूद मेरे पास है (जैसे उपयोग करना Google oAuth API जैसी चीजें जहां मुझे पहले लॉगिन पर दिए गए टोकन को रखने और ट्रैक करने के लिए सर्वर की आवश्यकता होती है)।

मुझे अभी तक पता नहीं चला है कि क्या यह संभव है, लेकिन अगर ऐसा है तो लोगों के लिए यह बहुत आसान होगा।

यदि नहीं, तो लोगों को विभिन्न विकल्पों के बारे में समझाने के लिए कहीं न कहीं यह एक अच्छा लिखने लायक है।

@trandainhan : अगर मैं <Link href="/">Home</Link> जोड़ता हूं, और फिर जेनरेट किए गए लिंक पर क्लिक करता हूं, तो मैं लॉग इन किए बिना index.js तक पहुंच सकता हूं। आप अपने उदाहरण में इसे ठीक करने का सुझाव कैसे देंगे?

@iaincollins मुझे यहां अधिकांश समाधान दिखाई देते हैं जो एक ओथ सेवा के विरुद्ध प्रमाणित होते हैं। क्या जेडब्ल्यूटी पर निर्भर एपीआई के खिलाफ प्रमाणीकरण के लिए कोई अच्छा समाधान है?

@paulwehner मुझे लगता है कि ऐसा इसलिए होता है क्योंकि @trandainhan ने केवल सर्वर साइड

@ कार्लोस-पेरू हुड के तहत, लिंक वास्तव में ब्राउज़र इतिहास में नए पथ को धक्का देने के लिए अगला/राउटर का उपयोग करता है। ऐसा लगता है कि अधिकांश चीजें ब्राउज़र द्वारा नियंत्रित की जाती हैं, सर्वर साइड पर मिडलवेयर के लिए यहां कुछ भी नहीं करना है। अब तक, मैं केवल अपना खुद का लिंक घटक बनाने के बारे में सोच सकता हूं और जब भी हम यूआरएल बदलते हैं तो अन्य चीजें करते हैं।

@ कार्लोस-पेरू रूटिंग पर पूर्ण नियंत्रण रखने के लिए आप हमेशा कस्टम सर्वर का उपयोग कर सकते हैं।

धन्यवाद @trandainhan और @kolpav! सप्ताहांत में कुछ समय बिताने के बाद मुझे बेहतर समझ मिली। मैं एक समाधान को लागू करने में भी कामयाब रहा जो एचओसी पर निर्भर करता है जो कुकी पर जेडब्ल्यूटी टोकन रखता है, इसलिए सर्वर और क्लाइंट दोनों एपीआई का उपभोग कर सकते हैं।

@nmaro मेरे पास next.js और एक ऐप (प्रतिक्रिया-मूल) में एक वेबसाइट के लिए जेडब्ल्यूटी प्रमाणीकरण के साथ बैकएंड है।

इसलिए। मुझे लगता है कि अगले मॉडल में: क्लाइंट एक फेसबुक टोकन प्राप्त करता है (उपयोगकर्ता फेसबुक लॉगिन स्वीकार करता है) और फिर क्लाइंट बैकएंड को टोकन भेजता है ताकि उपयोगकर्ता टोकन की जांच और सत्यापन किया जा सके (नोड-जेएस बैकएंड में पासपोर्ट-फेसबुक-टोकन) . फिर, यदि टोकन अच्छा है, तो बैकएंड क्लाइंट को बैकएंड में उत्पन्न JWT को भेजता है।

समस्या? आपका टूल फेसबुक और गूगल से कुंजी प्राप्त कर सकता है? मैं hello.js का उपयोग कर रहा हूं, लेकिन next.js के साथ संगत नहीं है और पूरी दुनिया पासपोर्ट-फेसबुक का उपयोग करती है। मुझे लगता है कि यह एक बड़ी गलती है क्योंकि एपीआई सर्वर को वेब क्लाइंट और मोबाइल ऐप के साथ संगत होना चाहिए।

शुक्रिया

पुनश्च: मुझे आपके सुस्त चैनल में निमंत्रण नहीं मिल रहा है।

@hmontes यहाँ - ओथ परियोजना के लिए सुस्त चैनल के लिए एक निमंत्रण (नोड के लिए उपयोगकर्ता खाते, विशेष रूप से next.js) में शामिल होने के लिए स्वतंत्र महसूस करें। ऊथ पासपोर्ट-फेसबुक-टोकन (पासपोर्ट-फेसबुक नहीं) और पासपोर्ट-गूगल-आईडी-टोकन का उपयोग करता है जो मुझे लगता है कि आपकी समस्या का समाधान करता है।

@nmaro मैं आपके प्रोजेक्ट में आपकी मदद करना चाहता हूं। मेरे पास ग्राफ़िकल के साथ पासपोर्ट-फेसबॉक और पासपोर्ट-गूगल-आईडी-टोकन के साथ बैकएंड भी है !!!

परंतु। क्या आप next.js में कनेक्ट facebook/google क्लाइंट के लिए एक संगत पैकेज जानते हैं?

क्लाइंट साइड पर आप मेरे द्वारा यहां इस्तेमाल किए गए समान पैटर्न का उपयोग कर सकते हैं: https://github.com/nmaro/staart/blob/master/packages/staart/src/components/login-facebook.js https://github. com/nmaro/staart/blob/master/packages/staart/src/components/login-google.js
( oothClient.authenticate बजाय बस अपने प्रमाणीकरण मार्ग पर एक पोस्ट अनुरोध भेजें)।

@timneutkens कम से कम ओथ उदाहरण के साथ एक पीआर का स्वागत किया जाएगा?

आपके उदाहरण में @nmaro । आप कंपोनेंटविलमाउंट के बजाय कंपोनेंटडिडमाउंट का उपयोग क्यों करते हैं?

मैं Google लॉगिन के लिए एक एचओसी (प्रदाता) घटक बना रहा हूं।

क्या कॉम्पोनेंटविलमाउंट केवल क्लाइंट पर कॉल किया जाता है? तब यह ठीक होना चाहिए।

ठीक है। आपके उदाहरणों के लिए बहुत-बहुत धन्यवाद। अंत में मैं सोशल मीडिया के साथ प्रमाणीकरण लागू कर सकता हूं।

आखिरी सवाल। मैंने एक एक्सेस_टोकन और रीफ्रेश_टोकन बनाया है और मैं डेटा को सहेजने के लिए स्थानीय स्टोरेज में रखना चाहता हूं।

पेज रीफ्रेश होने पर लॉगिन जांचने के लिए मैं इसे next.js में कहां रख सकता हूं? क्रिएट-रिएक्शन-ऐप में मैंने इसे index.js . में रखा है

...
import { loginUser } from './actions'
...
let accessToken = localStorage.getItem('access_token')
let refreshToken = localStorage.getItem('refresh_token')

if (accessToken && refreshToken) store.dispatch(loginUser({accessToken, refreshToken}))

ReactDOM.render(
  <ApolloProvider store={store} client={client}>
....

शुक्रिया

ओह के साथ, मैं फेसबुक टोकन स्टोर नहीं करता, मैं केवल पासपोर्ट के साथ उनका उपयोग करता हूं और फिर सामान्य कुकी-आधारित उपयोगकर्ता सत्र बनाता हूं।

आह। ठीक है। मैं सत्र के बजाय जेडब्ल्यूटी का उपयोग कर रहा हूँ। तो, मैं बैकएंड को access_token भेजता हूं, यह जांचता है कि टोकन सेवा (गूगल, फेसबुक) में मान्य है, तो यदि उपयोगकर्ता मेरे ऐप में मौजूद है और मुझे एक जेडब्ल्यूटी वापस भेजता है।

शुक्रिया :)

मुझे यह जोड़ना चाहिए कि स्थानीय स्टोरेज (एक्सएसएस की वजह से) में जेडब्ल्यूटी को स्टोर करना खतरनाक है, अगर यह सब एक सर्वर/डोमेन में है तो उन्हें कुकीज़ के रूप में भेजने के लिए बेहतर है, इसलिए क्लाइंट जावास्क्रिप्ट कोड जेडब्ल्यूटी नहीं प्राप्त कर सकता है, लेकिन ब्राउज़र भेज देगा JWT स्वचालित रूप से कुकीज़ के रूप में। जेडब्ल्यूटी मुश्किल हैं (ऊपर लंबी चर्चा देखें), इसलिए मैं सत्र का उपयोग करता हूं।

मैं एक जेडब्ल्यूटी का उपयोग केवल तभी करता हूं जब ओथ को बाहरी प्रमाणीकरण माइक्रोसर्विस के रूप में उपयोग किया जाता है (क्योंकि कुकीज़ केवल एक ही डोमेन पर काम करती हैं), और फिर भी मैं इसे सर्वर के साथ एक सत्र बनाने के लिए बिल्कुल एक बार उपयोग करता हूं, इसलिए यह क्लाइंट पर कहीं भी संग्रहीत नहीं होता है .

JWT सुरक्षा बढ़ाने के लिए आप एक ताज़ा टोकन (oauth2 से लिया गया) का उपयोग कर सकते हैं।

एक मोबाइल ऐप कुकीज़ को संभाल सकता है?

@नमारो ओके। मैं तुम्हें समझता हूं। मेरी त्रुटि के लिए क्षमा करें।

क्या आपके पास JWT टोकन को कुकी में सहेजने के लिए कोई ट्यूटोरियल या कोड है? मैं देख रहा हूँ https://github.com/zeit/next.js/blob/master/examples/with-firebase-authentication (मेरा ऑथ सिस्टम ग्राफ़िकल के साथ है)

नहीं, क्षमा करें, मैंने ऐसा कभी नहीं किया।

@hmontes @nmaro
मैंने इसे अपने लिए लिखा है, लेकिन मदद कर सकता है:
https://github.com/malixsys/mobazoo

अरे @malixsys साझा करने के लिए धन्यवाद। आपके कोड से मुझे कुछ समझ नहीं आ रहा है: ऐसा लगता है कि आप API_BASE_URL को किसी बाहरी अधिकार से कॉन्फ़िगर करेंगे? यदि आप उस एपीआई की ओर प्रमाणित करते हैं तो मुझे लगता है कि यह कुकी-आधारित सत्र शुरू करेगा, है ना? लेकिन फिर, आप उस कुकी को next.js सर्वर पर कैसे स्थानांतरित करते हैं, यह मानते हुए कि अगला.js सर्वर किसी अन्य डोमेन पर है?

आह नहीं, मैं देख रहा हूँ, आप उसी प्रक्रिया में /auth/signin सेट करते हैं। ठीक है, तो यह मूल रूप से वही दृष्टिकोण है जिसका उपयोग मैंने अगले.जेएस / स्टार के साथ ओथ के लिए किया था।

असल में नहीं, मैं अभी भी उलझन में हूं:/auth/signin में आप एक जेडब्ल्यूटी वापस देते हैं, लेकिन आप क्लाइंट साइड पर इसके साथ कुछ भी नहीं करते हैं। बाद में आप "getUserFromCookie" लेकिन मुझे नहीं पता कि आपने कुकी कहां सेट की है।

@nmaro मैं शुरुआत में सार्वभौमिक के साथ काम करने के लिए बस एक बुनियादी लॉगिन चाहता था। मैंने अभी के लिए एक jwt और एक कुकी दोनों सेट की हैं। कुकी सार्वभौमिक करने के लिए प्रयोग किया जाता है। मैंने अभी तक इस रेपो में किसी अन्य axios कॉल में jwt का उपयोग नहीं किया है। मैं एक निजी कांटा में करता हूं जहां API_BASE_URL दूसरे डोमेन को इंगित करता है ...
यह सब मेरी TODO सूची में है, PWA के साथ।
कृपया बेझिझक कोई मुद्दा खोलें या मुझे यहां पिंग करें...

@nmaro कुकी यहां saveUser() में सेट है: https://github.com/malixsys/mobazoo/blob/master/utils/auth.js

@nmaro ने https://github.com/malixsys/mobazoo/blob/master/pages/profile.js पर दोबारा काम किया

मुझे पता है कि यह मुद्दा बंद हो गया है, लेकिन मैं अपना समाधान दिखाना चाहता हूं।
https://next-auth.now.sh/
मुझे लगता है कि यह कुछ हद तक zeit.co . की वेबसाइट के समान है

अप्रैल 9

मैंने इस पर कुछ काम किया है, वर्तमान में अन्य सामानों से भरा हुआ है हर तरह से यह मेरी प्राथमिकताओं की सूची में बहुत अधिक है

सितम्बर 22 #2974

हम जल्द ही एक आधिकारिक प्रमाणीकरण उदाहरण जारी करने की योजना बना रहे हैं, क्या आप इसे अलग भंडार के रूप में जारी कर सकते हैं? थांक्स!

@timneutkens

नमस्ते, आपको इसके बारे में फिर से बताने के लिए खेद है, लेकिन क्या आप कृपया साझा कर सकते हैं कि आधिकारिक लेख उदाहरण की स्थिति कैसी है? यह निश्चित रूप से कुछ ऐसा है जिसे मैं देखना पसंद करूंगा और इस मुद्दे पर अन्य लोगों की टिप्पणियों की संख्या के आधार पर भी निर्णय करूंगा। तो यह प्राथमिकताओं की सूची में कितना ऊंचा है और क्या हमें अपनी आशाओं पर खरा उतरना चाहिए? मैं

नमस्ते @kolpav , उन्होंने आधिकारिक तौर पर Next.js 5 के रोडमैप के रूप में इसकी घोषणा की है।

अंत में, हम कुछ अत्यधिक अनुरोधित उदाहरण (जैसे उपयोगकर्ता प्रमाणीकरण), Next.js इंटर्नल के लिए बेहतर दस्तावेज़ीकरण और छोटी सुविधाएँ और बग समाधान जोड़ रहे हैं।

https://zeit.co/blog/next-canary#the -roadmap

@babenzele यह बहुत अच्छी खबर है। मुझे याद आया होगा कि

हम Next.js 5 के विकास के बारे में कहां अपडेट रह सकते हैं? मैं इस समय auth0 को एकीकृत कर रहा हूं, लेकिन एक आधिकारिक nextjs auth पथ/उदाहरण का पालन करने के लिए बहुत अच्छा होगा

ऐसा लगता है कि नेक्स्ट.जेएस को जेडब्ल्यूटी/कुकीज़/लोकलस्टोरेज (या उनमें से एक संयोजन, जब तक कि यह एक्सएसएस/सीएसआरएफ से सुरक्षित और संरक्षित है) का उपयोग करते हुए एक आधिकारिक स्थानीय प्रमाणीकरण उदाहरण की सख्त जरूरत है ... मैंने कोशिश करने में कई सप्ताह बिताए एक Passport.js स्थानीय रणनीति के साथ एक अलग एक्सप्रेस एपीआई सर्वर का उपयोग करके इसके साथ आएं। मैंने स्टेटलेस अनुरोधों के लिए कुकी/लोकलस्टोरेज में जेडब्ल्यूटी की कोशिश की, और जब मैंने अंततः जेडब्ल्यूटी और स्टेटलेसनेस को छोड़ दिया तो मैंने एक्सप्रेस-सेशन मिडलवेयर से सत्र आईडी के साथ नियमित कुकी की भी कोशिश की। एक्सप्रेस-सत्र के काम करने के तरीके के कारण एक्सप्रेस एपीआई सर्वर पर अतिरिक्त सत्र बनाए जा रहे थे, जहां मैं समस्याओं में चल रहा था (saveUninitialized: false के साथ प्रयास किया गया)। मैंने अपने Next.js ऐप में एक्सप्रेस कोड को server.js में ले जाने पर विचार किया, लेकिन मैं वास्तव में इसे एक अलग सर्वर बनाना चाहूंगा। मुझे पूरा यकीन है कि मेरा कार्यान्वयन XSS/CSRF या कुकी अपहरण से सुरक्षित नहीं है। हमें एक आधिकारिक उदाहरण की आवश्यकता है जो स्थानीय प्रमाणीकरण/लॉगिन के लिए सर्वोत्तम प्रथाओं को शामिल करता है, या शायद Next.js के हिस्से के रूप में एक आधिकारिक मॉड्यूल जो हमारे लिए जटिलताओं को संभालेगा!

जबकि हम Next.js 5.x और आगे के उदाहरणों की प्रतीक्षा कर रहे हैं, आप https://nextjs-starter.now.sh पर एक नज़र डालना चाहेंगे जो अभी भी सक्रिय रूप से बनाए रखा गया है और एक्सप्रेस, एक्सप्रेस सत्र, सीएसआरएफ के साथ नेक्स्ट.जेएस का उपयोग करता है ( सीआरएसएफ टोकन), एक्सएसएस (सत्र टोकन के लिए केवल HTTP कुकीज़) और ओएथ और ईमेल का समर्थन करने के लिए पासपोर्ट जेएस का उपयोग करता है।

मैं वास्तव में एक मॉड्यूल में ऑथ कोड को रीफैक्टर करने की प्रक्रिया में हूं, जिससे उपयोग में आसान तरीके से Next.js प्रोजेक्ट्स में प्रमाणीकरण जोड़ना वास्तव में आसान हो गया है। स्टार्टर प्रोजेक्ट उदाहरण से कोड का एक गुच्छा कॉपी किए बिना, मॉड्यूल को आपको किसी भी डेटाबेस के साथ आसानी से इसका उपयोग करने की अनुमति देनी चाहिए। मैं इस सप्ताह इसके साथ किए जाने की उम्मीद कर रहा हूं।

संदर्भ के लिए, "डबल सबमिट कुकी" विधि सीएसआरएफ सुरक्षा जोड़ने का एक आसान तरीका प्रदान करती है यदि आप एक सरल लेकिन सुरक्षित दृष्टिकोण की तलाश में हैं।

स्थानीय स्टोरेज में जेडब्ल्यूटी के साथ समस्या यह है कि यह क्लाइंट साइड जावास्क्रिप्ट से हमेशा पठनीय है, इसलिए यदि आपके पास अविश्वसनीय सामग्री है (उदाहरण के लिए उपयोगकर्ता द्वारा सबमिट की गई सामग्री या विज्ञापन)।

यदि आप सत्र टोकन के लिए केवल HTTP कुकीज़ का उपयोग करते हैं - या केवल HTTP में टोकन मान के साथ JWT जैसा कुछ (या संपूर्ण JWT को एन्क्रिप्ट करें और सर्वर पर केवल HTTP टोकन का उपयोग करके इसे डिक्रिप्ट करें) - तो सत्र उतने ही सुरक्षित हैं जितने वे कर सकते हैं होना। विचार सिर्फ इतना है कि, आदर्श रूप से, सत्र टोकन विशेष रूप से क्लाइंट साइड जावास्क्रिप्ट के माध्यम से पठनीय नहीं होना चाहिए।

निश्चित रूप से बहुत सी साइटें केवल HTTP कुकीज़ का उपयोग नहीं करती हैं क्योंकि यह सिंगल पेज ऐप्स के लिए एक दर्द है, और इसमें हमेशा सामने के अंत में कुछ तर्क तर्क शामिल होते हैं, लेकिन यह अभी भी आदर्श दृष्टिकोण है।

एक अन्य विकल्प अभी भी https://github.com/nmaro/ooth है जो सक्रिय रूप से बनाए रखा जाता है, पहले से ही पैकेज में आता है और कुछ उत्पादन ऐप्स में उपयोग किया जा रहा है।

@iaincollins मैंने Next.js स्टार्टर प्रोजेक्ट डाउनलोड किया और इसे देखना शुरू किया। मुझे महत्वपूर्ण सुरक्षा-संबंधी (XSS/CSRF) भागों को अलग करना होगा और उन्हें अपने एप्लिकेशन में एकीकृत करने का प्रयास करना होगा, या जब तक आप अलग मॉड्यूल समाप्त नहीं कर लेते, तब तक प्रतीक्षा करें। क्या कहीं मैं उस मॉड्यूल के विकास पर नज़र रख सकता हूँ?

हाय @ केलेग1 ,

अन्य परियोजनाओं में उपयोग करना आसान बनाने के लिए अलग मॉड्यूल अब अगले-प्रमाणित मॉड्यूल के रूप में प्रकाशित किया गया है। इसमें एक उदाहरण प्रोजेक्ट शामिल है जो दिखाता है कि इसका उपयोग कैसे किया जाए।

आगे के संदर्भ के लिए, nextjs-starter.now.sh प्रोजेक्ट अब नेक्स्ट-

हालांकि यह अभी भी कुछ जटिल है, इसलिए यदि आपके पास एक मौजूदा ऐप है तो आपको संदर्भ के रूप में उपयोग करना आसान हो सकता है, लेकिन यदि ऐसा है तो मुझे उम्मीद है कि यह मदद करता है

ध्यान दें: सीएसआरएफ अभी भी इसमें काफी मजबूती से जुड़ा हुआ है। यह लुस्का का उपयोग करता है इसलिए मानता है कि res.locals._csrf सेट है, लेकिन विभिन्न सीएसआरएफ पुस्तकालय अलग-अलग निजी वर्र्स का उपयोग करते हैं।

मैं सराहना करता हूं कि यह अभी भी किसी भी व्यक्ति की तुलना में उपयोग करने के लिए और अधिक जटिल है, लेकिन कम से कम अब ऑथ कोड को मॉड्यूल में अलग कर दिया गया है ताकि मैं रिफैक्टर शुरू कर सकूं। मुझे उम्मीद है कि समय के साथ इसका उपयोग करना आसान हो जाएगा (विभिन्न डेटाबेस के लिए डिफ़ॉल्ट हैंडलर और oAuth के आसान कॉन्फ़िगरेशन के साथ)।

@iaincollins ऐसा लगता है कि next.js पर एकमात्र निर्भरता https://github.com/iaincollins/next-auth/blob/master/index.js#L342 है ? यदि ऐसा है, तो लिब को अगला बनाना बहुत अच्छा होगा। जेएस-अज्ञेयवादी।

@sedubois पूरी तरह सहमत हैं!

हालाँकि यह शायद यहाँ के बजाय इसके GitHub रेपो मुद्दों के लिए एक अच्छी चर्चा है। 🙂 यदि आप ऐसे तरीके सुझाना चाहते हैं जिन्हें सुधारा जा सकता है, सरल बनाया जा सकता है और अधिक सामान्य बनाया जा सकता है तो सहयोग करना पसंद करेंगे।

(कुछ ऐसा होना जो अगले के साथ उपयोग करना जितना आसान हो सके, अभी भी एक प्राथमिक लक्ष्य है, लेकिन मुझे नहीं लगता कि इसे अनन्य होना चाहिए, भले ही यह अगले विशिष्ट केंद्रित विकल्पों के साथ भी समाप्त हो।)

@timneutkens nextjs 5 की रिलीज़ पर बधाई। निकट भविष्य में हम उदाहरण फ़ोल्डर में एक आधिकारिक स्थानीय प्रमाणीकरण उदाहरण को जोड़ते हुए देखेंगे? या यह अभी भी बाद में रिलीज के लिए काम कर रहा है?

Ooth के पास अब एक व्यापक दस्तावेज़ीकरण है, जिसमें next.js प्रमाणीकरण की विशिष्टताएँ शामिल हैं।

@jaredpalmer मुझे आपका दृष्टिकोण पसंद है, मैंने आपके कार्यान्वयन के कुछ हिस्सों की प्रतिलिपि बनाई है। हालांकि, क्या getUser विधि सुरक्षित है? क्या होगा यदि कोई स्थानीय स्टोरेज के भीतर स्ट्रिंग को हाथ से बदलता है, तो क्या यह इस पर भरोसा करने के लिए आवेदन के लिए स्मार्ट होगा? क्या इसे उस विधि में बदलने के लिए और अधिक समझदारी होगी जो हर बार टोकन के जेडब्ल्यूटी सार्वजनिक हिस्से को डीकोड करता है और वहां से उपयोगकर्ता स्थिति पढ़ता है? इस तरह हम चीजों की जेडब्ल्यूटी प्रकृति के कारण इस राज्य पर अधिक भरोसा कर सकते हैं। आपकी क्या राय है?

आपको इसे कुकी में स्टोर करना चाहिए। मैंने लिखा है कि इससे पहले नेक्स्ट के पास कस्टम सर्वर के लिए सपोर्ट था।

@jaredpalmer क्या आप मुझे इसके बारे में और बता सकते हैं? क्या हमें स्थानीय भंडारण के बजाय कुकीज़ में सब कुछ स्टोर करना चाहिए? क्या आपका एचओसी भी अलग होगा? क्या इसका मतलब यह है कि अब हम सर्वर साइड रेंडरिंग प्रोटेक्टेड वेबसाइटों के लिए getInitialProps पद्धति का उपयोग कर सकते हैं?

बस ध्यान दें _अगर आप जो स्टोर करने की बात कर रहे हैं वह स्थानीय स्टोरेज/वेब स्टोरेज में संवेदनशील डेटा है_:

"वेब स्टोरेज का उपयोग करके संवेदनशील डेटा को कभी भी स्टोर न करें: वेब स्टोरेज सुरक्षित स्टोरेज नहीं है। यह कुकीज़ से "अधिक सुरक्षित" नहीं है क्योंकि यह तार पर प्रसारित नहीं होता है। यह एन्क्रिप्टेड नहीं है। कोई सुरक्षित या HTTP केवल ध्वज नहीं है इसलिए यह सत्र या अन्य सुरक्षा टोकन रखने का स्थान नहीं है।"

• https://www.whitehatsec.com/blog/web-storage-security/

लॉगिन के बाद कुकी में टोकन सेट करें। कुकी-जेएस का प्रयोग करें। फिर सर्वर पर एक्सप्रेस कुकी पार्सर का उपयोग करें ताकि आप req.headers.cookies.myToken या समकक्ष प्राप्त करने के लिए जांच कर सकें। एक हॉक के getInitialProps में जांचें कि क्या req मौजूद है, फिर req.cookies से टोकन लें, अन्यथा इसे क्लाइंट पर कुकीज से प्राप्त करें। प्राप्त करें ('mytoken')। इस बिंदु पर आपके पास क्लाइंट और सर्वर पर अपने टोकन तक पहुंच होगी। फिर आप एक भ्रूण/अक्षीय आवरण/उदाहरण बनाना चाहते हैं और इसे getInitialProps में अगले के ctx के साथ मर्ज करना चाहते हैं ताकि आपके सभी पृष्ठों के पास प्रमाणीकृत आइसोमोर्फिक अनुरोध करने का एक तरीका हो। आप अपने उपयोगकर्ता को भी हॉक में लाना चाह सकते हैं। इसलिए आपको इसे हर जगह दोहराने की जरूरत नहीं है। यदि आपको सामान्य संस्थाओं जैसे कि withUser(withTeam(Page)) की आवश्यकता है तो आप और अधिक हॉक्स बना सकते हैं

getUser एक बुरा विचार है, आपको केवल टोकन स्टोर करना चाहिए।

@jaredpalmer मैंने लगभग उसी तरह एक दृष्टिकोण बनाया और सब कुछ ठीक काम कर रहा है। जिस समस्या को मैं अभी हल करने का प्रयास कर रहा हूं वह है टोकन को रीफ्रेश कैसे करें। मैं जिस एपीआई के साथ काम कर रहा हूं वह अपेक्षाकृत अल्पकालिक टोकन (2 घंटे) है और मैं ऐप का उपयोग करते समय उपयोगकर्ता को लॉग इन रखने के लिए कुछ सिस्टम के आसपास अपना सिर लाने की कोशिश कर रहा हूं।
क्या आपके पास उस पर कोई इनपुट है?

आप अपने उपयोगकर्ता के लिए next.js के माध्यम से डेटा पास न करके भी प्रत्येक पृष्ठ संक्रमण पर एक अनुरोध सहेज सकते हैं। ऐसा करने के लिए आप सर्वर.जेएस में कुकी से टोकन पढ़ेंगे और उपयोगकर्ता को लाने का प्रयास करेंगे और उसे अगले अनुरोध हैंडलर को भेज देंगे। दस्तावेज़ में, इसे प्रॉप्स से प्राप्त करें और इसे JSON में window.USER की तरह स्टोर करें। फिर अपने हॉक में, आप इसे क्लाइंट लैंड में विंडो से पढ़ते हैं। अंत में, आपको एक प्रतिक्रिया इंटरसेप्टर के साथ axios का उपयोग करना चाहिए जो 403 कोड प्राप्त होने पर आपकी कुकी को तुरंत मिटा देता है और पृष्ठ को पुनः लोड करता है

@pbrandone दोहराव के बावजूद, सबसे सरल और सबसे अनुमानित समाधान है कि आप अपने टोकन को हर अनुरोध के साथ भेजें, प्रतिक्रिया के हेडर/बॉडी में एक नया-ताज़ा टोकन प्राप्त करें। आपका ग्राहक प्रत्येक अनुरोध/प्रतिक्रिया चक्र पर अपने ज्ञात मूल्य को अद्यतन करता है, प्रभावी रूप से एकल-उपयोग वाले टोकन प्रदान करता है जो कभी पुराने नहीं होते हैं और जिनका दुरुपयोग नहीं किया जा सकता है।

आम तौर पर, इस दृष्टिकोण के साथ, /token/refresh का उपयोग केवल एप्लिकेशन के प्रारंभिक "वेक अप" के लिए किया जाता है (सोचें componentWillMount हुक <App/> ), यह देखने के लिए जांच कर रहा है कि अंतिम सहेजा गया है या नहीं टोकन अभी भी मान्य और प्रयोग करने योग्य है।

रीफ्रेश टोकन से कभी भी निपटना नहीं था, लेकिन मैं इसे एक अक्षीय इंटरसेप्टर में करने की कोशिश करता हूं। इसके बारे में और सोचना होगा, लेकिन सिद्धांत रूप में आप एक खराब रिक को रोकेंगे, फिर नया टोकन प्राप्त करने के लिए रीफ्रेश टोकन का उपयोग करें, कुकी को नए टोकन के साथ सेट करें, और नए टोकन के साथ पहले अनुरोध को दोबारा दोहराएं। Axios इंटरसेप्टर वास्तव में शक्तिशाली हैं क्योंकि वे आपको इस तरह की सामग्री को अपने उत्पाद कोड से अमूर्त और दृष्टि से बाहर रखने की अनुमति देते हैं। आपको एक अनुरोध और प्रतिक्रिया इंटरसेप्टर लिखने की आवश्यकता हो सकती है और/या प्रगति वस्तु/मानचित्र में किसी प्रकार का स्टेटफुल पकड़ सकता है जो बालों वाली हो सकती है। उम्मीद है कि यह मदद करता है

या वही करो जो लूका ने कहा था। बहुत आसान।

यदि आप टोकन रीफ्रेश करना चाहते हैं, तो आपको कस्टम सर्वर सेटअप के माध्यम से कुकी (यदि आप कुकीज़ का उपयोग कर रहे हैं) को रोकना होगा। मैंने एक्सप्रेस का उपयोग करके ऐसा किया। अन्यथा आप जेडब्ल्यूटी टोकन का उपयोग करके इसे सभी क्लाइंट साइड कर सकते हैं। चूंकि मैं कुकीज़ के माध्यम से अपना काम कर रहा था, मेरे पास 2 उपयोग के मामले थे - क्लाइंट साइड पर नेविगेशन अनुरोधों को संभालना, और सर्वर-साइड पर पेज अनुरोध (कभी भी कोई मैन्युअल रूप से यूआरएल में टाइप करता है या पेज रीफ्रेश हिट करता है।) लेकिन मूल रूप से वे एक ही प्रवाह हैं एक क्लाइंट-साइड है और एक सर्वर-साइड है, बस अलग-अलग निष्पादित किया गया है। सर्वर-साइड पर जब से मैंने एक्सप्रेस का उपयोग किया है, मैंने कुकी को संसाधित करने, उसके अंदर जेडब्ल्यूटी को डीकोड करने और समाप्ति की जांच करने के लिए अभी एक मिडलवेयर बनाया है। यदि यह समाप्त हो गया था, तो नया टोकन प्राप्त करने का अनुरोध करें और डिकोड किए गए उपयोगकर्ता को क्लाइंट पर रिडक्स करने के लिए पास करना जारी रखें। क्लाइंट पर मेरे पास सुरक्षित लिंक के लिए एक एचओसी रैपर है जो लगातार उपयोगकर्ता की जांच कर रहा है, हर बार जब आप क्लाइंट पर कहीं भी नेविगेट करते हैं। एचओसी आपकी कुकी या जेडब्ल्यूटी प्राप्त करेगा, (मेरे मामले में मेरा जेडब्ल्यूटी एक कुकी में है) और जांचें कि यह अभी भी जल्दी से वैध है या नहीं। यदि यह मान्य नहीं है, तो यह एक ताज़ा JWT/कुकी प्राप्त करने का प्रयास करेगा, और जारी रखेगा, अन्यथा यह आपको लॉग आउट कर देगा। हाँ अधिक जटिल, लेकिन अधिक सुरक्षित भी। उम्मीद है की वो मदद करदे! यदि आप रुचि रखते हैं तो बेझिझक प्रश्न पूछें - यह सब पता लगाने में मुझे कुछ समय लगा। मैं व्यक्तिगत रूप से जीथब या एफबी आदि के साथ लॉगगिन लोगों के बारे में सोचता हूं - शायद बहुत सारे मामलों के लिए ठीक है लेकिन कुछ मामलों में यह सिर्फ पेशेवर नहीं है। मुझे अभी तक कोई बैंक, स्वास्थ्य सेवा, मेरे द्वारा भुगतान किए गए किसी भी बिल आदि को देखना है - मुझे अपने एफबी खाते से लॉग इन करें। हालांकि बस समय की बात हो सकती है;)

पहुंच टोकन को ताज़ा करने के लिए;
मुझे यकीन नहीं है कि यह करने का यह एक उचित तरीका है, लेकिन मेरी पहुंच टोकन बहुत ही अल्पकालिक (एक मिनट या उससे भी अधिक) हैं। क्लाइंट-साइड टोकन समाप्ति समस्याओं से निपटने के लिए मैंने यह तरीका अपनाया है;
हर बार जब कोई पृष्ठ लोड होता है तो यह जांचता है कि टोकन समाप्त हो गया है या नहीं, यदि ऐसा है, तो यह इसे रीफ्रेश करता है। हालांकि, अगर यह अभी भी मान्य है तो यह विधि को कॉल करता है जो जांचता है कि समाप्ति तक कितना समय है, और टाइमआउट सेट करता है जो समाप्ति पर पहुंच टोकन रीफ्रेश करेगा। और फिर इस प्रक्रिया को तब तक दोहराता है जब तक आगंतुक साइट पर है।

callRefreshAuthenticationLater(){
    clearTimeout(this.accessTokenRefreshmentTimeout)
    this.accessTokenRefreshmentTimeout = setTimeout(() => {
      this.refreshAuthentication()
    }, this.authService.howMuchUntilExpiration(this.authService.getToken('access_token')))
  }

यह समाप्ति तक मिलीसेकंड लौटाता है:

howMuchUntilExpiration(token){
    return normalizeTimestamp(jwtDecode(token).exp) - Date.now()
  }

इस दृष्टिकोण के लिए किसी भी प्रतिक्रिया का स्वागत किया जाएगा

@ कुनोकदेव - मुझे लगता है कि यह एक अच्छी शुरुआत है। मैंने एक समान func को स्थानांतरित कर दिया, मुझे शेष समय की गणना एक func पर करनी पड़ी जो कि यह समाप्त हो गया था या नहीं, इस पर निर्भर करता है कि यह एक बूलियन लौटाता है और इससे मेरा कोड थोड़ा अधिक पठनीय और सरल हो जाता है और मुझे टाइमर रीसेट करने के बारे में चिंता करने की आवश्यकता नहीं होती है। फिर मैं सिर्फ यह जांचता हूं कि उपयोगकर्ता की समय सीमा समाप्त हो गई है या नहीं, किसी भी प्रकार के अनुरोध पर जिसके लिए प्रमाणीकरण की आवश्यकता है। अगर मेरे पास उलटी गिनती टाइमर या ऐसा कुछ है जो क्लाइंट या डिबगिंग के लिए दृश्यमान था तो आपका कार्य आदर्श होगा। वह मेरे 2 सेंट

क्या लेख/लॉगिन उदाहरण सबसे बुनियादी संभव नहीं होना चाहिए? यानी मेमोरी स्टोर और कोई जेडब्ल्यूटी या अजीब टोकन चीजें नहीं। आम तौर पर जब आप किसी के बारे में सोचते हैं "लॉग इन" इसका मतलब है कि उनके पास कुकी/सक्रिय सत्र है।

मेरे पास एक लॉगिन एचओसी वर्किंग क्लाइंट और सर्वर साइड है। यह एक जेडब्ल्यूटी और बैकएंड का उपयोग करता है (नोड, डीजेंगो, जो भी हो सकता है)।

इसे देखें और किसी भी प्रतिक्रिया की अत्यधिक सराहना की जाती है

https://github.com/hugotox/AppStarter

यहां प्रासंगिक कोड https://github.com/hugotox/AppStarter/blob/master/src/components/auth/login-required.js

@hugotox मुझे store.dispatch से getInitialProps कॉल करते हैं तो कई बार अवांछित साइड इफेक्ट्स के लिए तैयार रहें, जब सजाए गए घटक को ऑथ प्रक्रिया के बावजूद प्रस्तुत किया जाएगा अभी समाप्त नहीं हुआ है। आइए अपने कोड से उपयोग उदाहरण लें:

export default withRedux(initStore, mapStateToProps)(
   loginRequired([PUBLIC])(MyPage)
)

getInitialProps आप verifyToken से पहले verificationOk कॉल करते हैं, इसलिए MyPage.mapStateToProps को 2 बार कॉल किया जाएगा (यदि यह store.auth.user के लिए सुनता है) और पहली बार store.auth.user उस पृष्ठ के लिए भी शून्य होगा जिसमें लॉग इन उपयोगकर्ता की आवश्यकता होती है।

कल मैंने अपने Next.js संचालित स्टार्टर किट का पहला WIP संस्करण भी जारी किया, लेकिन मैंने Docker, Flow और Fast-redux के साथ शुरुआत की: https://github.com/dogada/microchain

मैं एपीआई सर्वर और वेबएप के लिए समर्पित डॉकर छवियों का उपयोग करता हूं जो विभिन्न डोमेन पर चल सकते हैं, इसलिए मैं अभी भी एक कामकाजी समाधान की तलाश में हूं जो वास्तविक उपयोगकर्ताओं को लॉगिन करने की अनुमति देगा लेकिन उदाहरण के लिए मोबाइल क्लाइंट के लिए ओएथ बियरर टोकन भी जारी करेगा।

@spencersmb उत्कृष्ट चीयर्स! यह बिल्कुल वैसा ही है जैसा मैं इसके बारे में जा रहा था। पहली बार किसी यूआरएल के लिए सर्वर साइड रेंडरिंग के संदर्भ में (कभी लॉग इन नहीं किया गया), क्या आप इसे केवल इंटरसेप्ट कर रहे हैं, यह देखते हुए कि कोई कुकी नहीं है और उदाहरण के लिए पेज/लॉगिन.जेएस टाइप पेज पर रीडायरेक्ट कर रहा है?

@ James-ff इसे पोस्ट करने के लिए धन्यवाद, भले ही यह शून्य में चिल्लाने जैसा लगता हो।

यह इस धागे में कुछ बार कहा गया है लेकिन हर कोई स्पष्ट रूप से अभी भी अनदेखा कर रहा है कि उन्हें स्थानीय स्टोरेज या जावास्क्रिप्ट सुलभ कुकीज़ के साथ जेडब्ल्यूटी में सत्र टोकन संग्रहीत नहीं करना चाहिए और कम सुरक्षित तरीके से सत्रों और प्रमाणीकरण को फिर से आविष्कार करने का प्रयास करने का इरादा है। (और इसके लिए क्लाइंट साइड जेएस की आवश्यकता है)। ‍♂️

इस पोस्ट के लेखक कि चीजों में सुधार नहीं हुआ है:

दुर्भाग्य से, ऐसा लगता है कि लोगों ने पढ़ना बंद करने से पहले मुझे लेख की लंबाई पर ऊपरी सीमा मिल गई है - रेडिट और हैकर न्यूज पर कई टिप्पणीकारों ने बार-बार एक ही "समाधान" का सुझाव दिया, पूरी तरह से अनदेखा कर दिया कि उन्हें पहले ही संबोधित किया गया था और अव्यवहारिक पाया गया था लेख में ही।

हालांकि मूल लेख और अनुवर्ती आरेख दोनों ही बहुत बढ़िया हैं।

@iaincollins JWTs और सत्र-रहित ऐप्स/प्रमाणीकरण के अपने फायदे हैं और बहुत से लोग/कंपनियां (Google सहित) अभी भी उनका उपयोग करना चाहते हैं। जेडब्ल्यूटी के खिलाफ मामले को पढ़ने के बाद, मुझे अभी भी लगता है कि दो आधिकारिक अगली-लेखक उदाहरण/पुस्तकालय होने चाहिए, एक सत्र का उपयोग करना (जैसे अगली-लेखक) और एक जेडब्ल्यूटी का उपयोग करना, या शायद केवल एक जो या तो उपयोग करने की अनुमति देता है। आधिकारिक Next.js ट्यूटोरियल पेज और/या मॉड्यूल दस्तावेज़ीकरण पर प्रत्येक के लिए फायदे, नुकसान और चेतावनियों को स्पष्ट रूप से समझाया जाना चाहिए। जब तक कोई बेहतर बॉयलरप्लेट/लाइब्रेरी का आविष्कार नहीं करता, मैं शायद नेक्स्टज-स्टार्टर और नेक्स्ट-ऑथ का उपयोग करना जारी रखूंगा, क्योंकि वे सबसे अच्छे हैं जो मुझे मिले हैं।

मैं इस पर केवल लापरवाही से नजर रखता रहा हूं, लेकिन यूनिवर्सल जेएस ऑथ के साथ मेरा अनुभव एक जेडब्ल्यूटी को HttpOnly कुकी में स्टोर करना है। जब आपके पास कुकी को स्टोर करने के लिए ऐप के सर्वर-साइड का उपयोग करने का विकल्प होता है, तो वास्तव में localStorage का उपयोग करने का कोई कारण नहीं होता है। यदि आपको ब्राउज़र में क्रॉस-ओरिजिनल एपीआई कॉल के लिए जेडब्ल्यूटी तक पहुंच की आवश्यकता है, तो आप जेडब्ल्यूटी को __INITIAL_STATE__ प्रकार के परिदृश्य में पास कर सकते हैं (एक्सएसएस कमजोरियों से अवगत रहें, लेकिन कम से कम आप "स्टोरिंग" नहीं कर रहे हैं यह क्लाइंट-साइड)। समान-मूल पहुंच के लिए, कुकी को आगे और पीछे पारित किया जाएगा (यह मानते हुए कि आप withCredentials का उपयोग axios के लिए कर रहे हैं, या credentials: 'include' लाने के लिए), JWT को JS में डालने की आवश्यकता को नकारते हुए . आप HttpOnly कुकी में से JWT को हथियाने के लिए ऐप के सर्वर-साइड पर एक प्रॉक्सी का उपयोग कर सकते हैं, _then_ अपनी क्रॉस-ओरिजिनल API कॉल भी कर सकते हैं। आप उस परिदृश्य में भी प्रीफ्लाइट कॉल को नकारते हैं। प्रत्येक के लिए, लेकिन मुझे व्यक्तिगत रूप से नहीं लगता कि सार्वभौमिक ऐप्स के लिए स्थानीय स्टोरेज की आवश्यकता है।

@bjunc हां, सभी विकल्पों में से जहां एक जेडब्ल्यूटी संग्रहीत किया जाना चाहिए (

मैंने नेक्स्टज-स्टार्टर और नेक्स्ट-ऑथ को अपनाना शुरू करने से पहले मैंने अपने प्रोजेक्ट में कमोबेश वही करने की कोशिश की, जो आपने मेरे प्रोजेक्ट में कहा था। यह एक समय हो गया है, लेकिन अगर मुझे सही से याद है तो मुझे लगता है कि मुझे जिस समस्या का सामना करना पड़ा वह यह था कि मेरा एक्सप्रेस एपीआई सर्वर जिसे मैं प्रमाणित कर रहा था (जो एक्सप्रेस-सत्र का उपयोग कर रहा था) सत्र को सही ढंग से प्रारंभ/प्राप्त नहीं कर रहा था। मुझे अजीब व्यवहार मिलेगा जहां सत्र कई बार शुरू किए जाएंगे। अगर मैं इसे ठीक कर सकता हूं तो मैंने जो वर्णन किया है उसे कम या ज्यादा करना फिर से शुरू करना चाहता हूं। मैं नेक्स्टज-स्टार्टर और नेक्स्ट-ऑथ के साथ भी काम करना जारी रखूंगा, क्योंकि सत्र जेडब्ल्यूटी की कई अन्य चिंताओं को दूर करते हैं, जैसे कि टोकन को कैसे अमान्य करना है।

दोबारा, एक आधिकारिक उदाहरण (या उदाहरण) सहायक होगा। मुख्य शब्द: आधिकारिक, जिसका अर्थ है Next.js के लेखकों ने सभी संभावनाओं पर विचार किया है और इसमें सर्वोत्तम विचारों और प्रथाओं को शामिल किया है। आदर्श रूप से आधुनिक ES6/ES7/ES8 सुविधाओं जैसे वादे और async/प्रतीक्षा का उपयोग करना।

@ kelleg1 ऐसा लगता है कि आपके मुद्दे कुकी निर्माण की बारीकियों से संबंधित हैं। उदाहरण के लिए, आप अलग-अलग सेटिंग्स ( HttpOnly , डोमेन, पथ, समाप्ति, आदि) का उपयोग करके गलती से एक ही नाम के साथ कई कुकीज़ बना सकते हैं; जो अजीब दुष्प्रभाव पैदा कर सकता है जैसे आप वर्णन कर रहे हैं। डिबग करने का एक तरीका यह है कि देव टूल्स एप्लिकेशन-> कुकीज का उपयोग किया जाए। यदि आप एक ही नाम से कुकीज़ का एक गुच्छा देखते हैं, तो यह आपको सही दिशा में इंगित कर सकता है।

वैसे भी, मैं कोर टीम में नहीं हूं, इसलिए मैं "आधिकारिक" योगदान के साथ मदद नहीं कर सकता (और वास्तव में, मैं Nuxt.js का उपयोग कर रहा हूं, Next.js का नहीं), लेकिन सिद्धांत समान हैं। मैंने ऐसा करने के कुछ अलग तरीकों के साथ प्रयोग किया (जेडब्ल्यूटी, कुकीज़, सीएसएफआर, वेबसोकेट सीएसडब्ल्यूएसएच, स्थानीय स्टोरेज, आदि के पेशेवरों/विपक्षों का वजन)। मैं अंततः इस निष्कर्ष पर पहुंचा कि नेक्स्ट/नक्स्ट की सार्वभौमिक प्रकृति ने खुद को HttpOnly JWT कुकीज़ के उपयोग के लिए अच्छी तरह से उधार दिया। हो सकता है कि अन्य लोग एक अलग निष्कर्ष पर आएं, लेकिन मैं व्यक्तिगत रूप से शिविर में नहीं हूं "हे भगवान, जेडब्ल्यूटी का उपयोग न करें, क्या आपने वह लेख नहीं पढ़ा जो कहता है कि जेडब्ल्यूटी आपको कैंसर देता है!"।

@iaincollins इसे फिर से वापस लाने के लिए खेद है, लेकिन वेब पर हर एक ट्यूटोरियल टोकन को बचाने के लिए

कुकीज़! :डी
हम कुछ इस तरह उपयोग करते हैं:

// auth.js
async signIn(res, info) {
    const { email, password } = info;
    const result = await this.service.signIn(email, password);
    if (!result) {
      res.status(HttpStatus.BAD_REQUEST).json({ success: false, message: 'Wrong email and/or password' });
      return;
    }
  const payload = {
    scope: 'appUser',
    userId: user.email,
    language: user.language,
    iat: moment().unix(),
    exp: moment().add(7, 'days').unix(),
    type: user.type,
    status: user.status
  };
    const token = jwt.sign(payload, ...);

    res.cookie('token', token, { domain: 'yourdomain.com', path: '/', secure: true, httpOnly: true, maxAge: 24 * 60 * 60 * 1000 * 7, signed: true });

    res.status(HttpStatus.OK).json({});
  }

// pages/index.js

class Index extends PureComponent {
  render() {
    return (
      <Layout title="home">
        <Home />
      </Layout>
    );
  }
}

Index.getInitialProps = async ({ req, res }) => {
  const auth = req ? getServerSideToken(req) : getClientSideToken();
  return { auth };
}
export default Index;

// utils/auth.js
const decode = ({ token }) => {
  const decoded = jwt.decode(token);
  const { userId, type = 'anonymous', status, language = 'en' } = decoded || {};
  return { user: { email: userId, type, status, language } };
};

export const getServerSideToken = (req) => {
  const { signedCookies } = req;

  if (!signedCookies) {
    return {};
  }
  try {
    return decode(signedCookies);
  } catch (parseError) {
    console.error(parseError, signedCookies);
    return {};
  }
};

export const getClientSideToken = () => {
  if (typeof window !== 'undefined') {
    const user = window.__USER__ || {};
    return { user };
  }
  return { user: {} };
};

// pages/_document.js
export default class extends Document {
  static async getInitialProps(ctx) {
    const props = await Document.getInitialProps(ctx);
    const info = getServerSideToken(ctx.req);
    return { ...props, ...info };
  }

  render() {
    const { user = {} } = this.props;
    const json = JSON.stringify(user);
    return (
      <html lang="en">
        <Head>
          <meta name="viewport" content="width=device-width, initial-scale=1" />
          <meta charSet="utf-8" />
          <link href="//fonts.googleapis.com/css?family=Kadwa:400,700|Work+Sans:100,300,600" rel="stylesheet" />
          <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.2.14/semantic.min.css" />
          <link rel="stylesheet" href="/static/site.css" />
        </Head>
        <body>
          <Main />
          <script
            dangerouslySetInnerHTML={{ __html: `__USER__ = ${json};` }}
          />
          <NextScript />
        </body>
      </html>
    );
  }
}

// somewhere.js
import axios from 'axios';
axios.defaults.withCredentials = true;
axios.post(`${apiBaseUrl}/some/path`, data)...

// somemiddleware.js
      const { signedCookies = {} } = req;
      const { token = '' } = signedCookies;
      if (token) {
        try {
          const info = jwt.verify(token, ...);
          req.user = await this.getUser(info.userId);
          if (req.user) {
            next();
            return;
          }
        } catch (err) {
          console.error({ permissionError: err });
          return res.status(500).json({...});
        }
      }
      return res.status(403).json({...});

क्लाइंट साइड जावास्क्रिप्ट कभी भी टोकन नहीं देखता है, लेकिन बहुत सुरक्षित लेकिन बहुत सुरक्षित है httpOnly, सुरक्षित, हस्ताक्षरित और axios या अन्य द्वारा स्वचालित रूप से भेजा जाता है ...

सीएफ https://github.com/zeit/next.js/pull/3955

हाय सब, अभी कुकीज़ और redux के साथ एक प्रामाणिक उदाहरण बनाया है। यहां देखें https://github.com/zeit/next.js/pull/4011

रुको तो यह मुद्दा कहाँ समाप्त हुआ? मुझे आधिकारिक रेपो में एक्सप्रेस ऑथ उदाहरण कभी नहीं मिला।

मुझे कुकीज़ और सत्रों के बारे में बहुत सारी बातें दिखाई देती हैं, लेकिन यह मेरे मूल मोबाइल ऐप के लिए कैसे काम करता है जब इसे एपीआई को हिट करने की आवश्यकता होती है?

@jackjwilliams को मोबाइल ऐप HTTP पुस्तकालयों को भी कुकीज़ का समर्थन नहीं करना चाहिए?
https://stackoverflow.com/questions/1660927/iphone-make-post-request-handle-cookie
https://stackoverflow.com/questions/678630/how-do-i-make-an-http-request-use-cookies-on-android

यह किया जा सकता है, लेकिन जेडब्ल्यूटी इसके लिए है: पी

मैंने अभी-अभी इस पूरे सूत्र का विस्तृत अध्ययन किया है और अपने निष्कर्षों को संक्षेप में बताने के लिए बाध्य महसूस कर रहा हूँ।

ऐसा प्रतीत होता है कि ठोस ऑथ मॉड्यूल के साथ दो व्यवहार्य स्टार्टर परियोजनाएं हैं:

• https://github.com/iaincollins/nextjs-starter -> https://github.com/iaincollins/next-auth
• https://github.com/nmaro/staart -> https://github.com/nmaro/ooth

@iaincollins और @nmaro द्वारा उत्कृष्ट कार्य!

मैंने नेक्स्टज-स्टार्टर के साथ काम करने के अपने शुरुआती अनुभवों पर एक

धन्यवाद @ करन :)

मैंने इस पुल अनुरोध https://github.com/iaincollins/nextjs-starter/pull/86 में नेक्स्टज-स्टार्टर के बाहरी पहलुओं को टटोलने के लिए किए गए सभी कोड परिवर्तनों का दस्तावेजीकरण किया।

यह नेक्स्ट.जेएस रिपॉजिटरी के लिए एक ठोस नंगे-हड्डियों प्रमाणीकरण उदाहरण के करीब हो रहा है।

मुझे हाल ही में Office 365 के साथ OAuth को लागू करने की आवश्यकता थी, इसलिए मैंने सोचा कि मैं एक बहुत ही सरल उदाहरण साझा करूँगा जिसे मैंने यहाँ एक साथ रखा का उपयोग करता है । किसी भी मामले में, मैंने सोचा कि अगर कोई माइक्रोसॉफ्ट के साथ (शायद) ऐसा करने का त्वरित उदाहरण चाहता है तो मैं साझा करूंगा।

एक साधारण जेडब्ल्यूटी टोकनयुक्त प्रमाणीकरण में दिलचस्पी रखने वाले किसी भी व्यक्ति के लिए जो क्लाइंट और सर्वर साइड काम करता है, मुझे स्पेक्ट्रम चैट में कुछ मदद मिली और मुझे लगा कि मैं इसे आप सभी के साथ साझा करूंगा। किसी भी प्रतिक्रिया की हमेशा सराहना की जाती है।

https://github.com/bgold0/nextjs-auth-skeleton

हाय दोस्तों!
अगले.जेएस के साथ प्रमाणीकरण का एक और उदाहरण यहां दिया गया है जिसे मैंने कुछ महीने पहले बनाया है, शायद किसी को यह उपयोगी लगेगा:

https://github.com/alan2207/nextjs-jwt-authentication

Ooth 2.0 नए और बेहतर दस्तावेज़ों के साथ आ गया है

Ooth एक उपयोगकर्ता पहचान प्रबंधन प्रणाली है जिसे node.js (अगले.js को ध्यान में रखते हुए) के लिए बनाया गया है।

वर्तमान में समर्थित रणनीतियाँ:

• प्राथमिक: उपयोगकर्ता नाम/पासवर्ड (ईमेल सत्यापित करें, pw भूल गए आदि), अतिथि, facebook, google
• माध्यमिक: कुकी-आधारित सत्र, JWTs

इस लाइव उदाहरण को देखें जो इसे next.js ( स्रोत कोड ) के साथ एक साथ रखता है।

यहां कई लेख नमूने (और उदाहरण फ़ोल्डर में) उपयोगकर्ता सत्र/टोकन/आदि को getInitialProps से लौटाते हैं। जहां तक ​​मैं समझता हूं, जब पृष्ठ को सर्वर-साइड प्रस्तुत किया जाता है, तो इसका अर्थ है कि उपयोगकर्ता सत्र की जानकारी ब्राउज़र को HTML पृष्ठ प्रतिक्रिया ( NEXT_DATA हिस्से के रूप में) के हिस्से के रूप में भेजी जाएगी।

जब getInitialProps सर्वर-साइड चलाया जाता है तो मुझे इस पैटर्न के साथ दो सुरक्षा समस्याएं दिखाई देती हैं:
1) उपयोगकर्ता सत्र सर्वर से ब्राउज़र में नेटवर्क पर प्रसारित हो जाता है। यदि ऐसा कोई अनुरोध http:// का उपयोग कर रहा है और https:// , तो उपयोगकर्ता के टोकन आदि को सादे-पाठ में नेटवर्क पर प्रदर्शित किया जाएगा।

2) उपयोगकर्ता सत्र को HTML पृष्ठ के भाग के रूप में सर्वर से ब्राउज़र में वापस किया जाता है ( NEXT_DATA स्क्रिप्ट टैग में)। उपयोगकर्ता के टोकन/आदि का सीधे HTML पृष्ठ पर बैठना जोखिम भरा लगता है, विशेष रूप से एक बार जब पृष्ठ को पार्स किया जाता है, ब्राउज़र द्वारा प्रस्तुत किया जाता है, और अन्य तृतीय-पक्ष स्क्रिप्ट अब चल रही हो सकती हैं।

क्या इन मुद्दों को पहले ही संबोधित किया जा चुका है? क्या इन खतरों के लिए कोई शमन है?

इसलिए मैं कुकीज़ का उपयोग करता हूं। मेरा उदाहरण यहां देखें https://github.com/hugotox/nextjs-starter/blob/master/pages/_app.js

https://github.com/zeit/next.js/pull/3955

आखिरकार! यहां आप निम्नलिखित कंटेनरों के साथ पूरी तरह से dockerized next.js auth उदाहरण पा सकते हैं:

• अगला.जेएस
• प्रामाणिक माइक्रोसर्विस (ऊथ)
• एपीआई (ग्राफक्ल)
• सत्र भंडारण (रेडिस)
• छोटा रिवर्स प्रॉक्सी

डॉकटर-कंपोज़ के साथ सब कुछ एक साथ खींचा जाता है।

JWTs पर त्वरित टिप्पणी। यदि आपको एक डोमेन से दूसरे डोमेन में क्रेडेंशियल पास करने की आवश्यकता है तो जेडब्ल्यूटी के पास स्टेटलेस, मोबाइल के लिए अच्छा और अच्छा होने के फायदे हैं। मुख्य नुकसान यह है कि वे ब्राउज़र को एक्सएसएस में बेनकाब करते हैं। इस उदाहरण के लिए मैंने एक शुद्ध कुकी-सत्र आधारित समाधान का विकल्प चुना। मैं अभी भी रिवर्स प्रॉक्सी (एक ही डोमेन के तहत चलने वाले सभी माइक्रोसर्विसेज) और साझा सत्र भंडारण के लिए धन्यवाद, माइक्रोसर्विसेज में चीजों को विभाजित करने में कामयाब रहा।

https://github.com/nmaro/staart/tree/master/examples/staart
लाइव उदाहरण हमेशा की तरह है: https://staart.nmr.io

मुझे लगता है कि यह स्पष्ट करना विवेकपूर्ण है, जेडब्ल्यूटी का उपयोग करना आपको एक्सएसएस के लिए आंतरिक रूप से "उजागर" नहीं करता है। इसके बजाय, यदि आपकी साइट में XSS भेद्यता है (स्वयं JWT के कारण नहीं), तो JWT से समझौता किया जा सकता है (किसी भी अन्य स्क्रिप्ट की पहुंच योग्य जानकारी के साथ); जबकि httpOnly कुकीज को एक्सेस नहीं किया जा सकेगा। कोई बात नहीं कि आप httpOnly कुकी के मूल्य के रूप में JWT का उपयोग कर सकते हैं!

कुकी-ओनली समाधान समान-डोमेन संचार के लिए अच्छी तरह से काम कर सकते हैं, लेकिन यदि आपके पास एक हेडलेस एपीआई है (उदाहरण के लिए example.com कॉलिंग api.example.com ), तो यह वास्तव में एक समाधान नहीं है जब तक कि आप प्रॉक्सी ब्राउज़र नहीं करना चाहते से अनुरोध example.com करने के लिए api.example.com करने के लिए अपने एपीआई कॉल करके example.com और उन पर आगे कुकी अनुरोध (जो पेशेवरों / विपक्ष के अपने स्वयं के सेट के साथ आता) के साथ जोड़ दिया साथ .

मैं व्यक्तिगत रूप से महसूस करता हूं कि जेडब्ल्यूटी के विपक्ष बहुत अधिक हैं, और आमतौर पर लागू सुरक्षा के माध्यम से बहुत आसानी से कम हो जाते हैं। इनमें से कम से कम, एक टोकन ब्लैकलिस्ट jti दावे (उदाहरण के लिए संस्करण 4 यूयूआईडी) का संदर्भ देता है, जिसमें टोकन की समाप्ति से पहले समझौता किया गया है।

अरे @bjunc हाँ स्पष्ट करने के लिए धन्यवाद। सही है, जेडब्ल्यूटी स्वयं आपको एक्सएसएस में उजागर नहीं करता है। आपकी अन्य टिप्पणियों के संबंध में, मैं यह जोड़ना चाहूंगा कि उनमें से प्रत्येक के अपने नुकसान हैं।

कोई बात नहीं कि आप JWT का उपयोग httpOnly कुकी के मान के रूप में कर सकते हैं!

हां, बस यह जोड़ना चाहेंगे कि डोमेन के बीच क्रेडेंशियल्स को स्थानांतरित करने के जेडब्ल्यूटी के एक लाभ को हटा दिया जाए।

एक टोकन ब्लैकलिस्ट

वह, और रीफ्रेश टोकन का अन्य सामान्य अभ्यास वास्तव में स्टेटलेस होने के जेडब्ल्यूटी के अन्य लाभ को हटा देता है।

यह स्थिति की मेरी समझ है:

• यदि आपको क्रॉस लोकेशन ऑथ की आवश्यकता है तो JWT <- का उपयोग करें, लेकिन यदि संभव हो तो सुरक्षा के कारण बचें
• यदि आपको किसी ऐसे क्लाइंट से प्रमाणीकरण करने की आवश्यकता है जो ब्राउज़र नहीं है और जिसमें XSS समस्या नहीं है (उदाहरण के लिए एक डेस्कटॉप या मोबाइल ऐप) JWT का उपयोग करें
• अन्यथा कुकी-आधारित सत्रों का उपयोग करें, क्योंकि JWT आधारित समाधान या तो कम सुरक्षित (XSS) होगा या वास्तव में स्टेटलेस (ब्लैकलिस्ट) नहीं होगा, या फिर भी आपको एक ही डोमेन के तहत सब कुछ रखने के लिए प्रॉक्सी का उपयोग करने की आवश्यकता होगी।

मैंने Next.js प्रमाणीकरण/उपयोगकर्ता खातों पर एक मध्यम लेख लिखा था।
यह लगभग दो वर्षों के खाली समय के विकास और सोच से एक व्यापक ट्यूटोरियल और मेरा ब्रेनडंप है (इस मुद्दे पर मेरी पहली टिप्पणी फरवरी 2017 से है)।

https://medium.com/the-ideal-system/user-accounts-with-next-js-an-extensive-tutorial-6831cdaed16b

आप JWT को कम सुरक्षित होने के साथ सहसंबंधित करते रहते हैं। JWT आपकी साइट को कम सुरक्षित नहीं बनाता है। यह अपने आप में एक XSS भेद्यता नहीं है। यदि आपके पास एक एक्सएसएस शोषण है, तो आप परवाह किए बिना समान परेशानी में हैं। यहां तक ​​​​कि httpOnly कुकी के साथ भी, हमलावर कुकी मूल्य को पढ़ने में सक्षम नहीं हो सकता है, लेकिन इससे कोई फर्क नहीं पड़ता क्योंकि वे मनमानी कोड चला सकते हैं - जैसे एक्सएचआर अनुरोध जो स्वचालित रूप से सत्र कुकीज़ पास करेंगे (अनिवार्य रूप से कार्य करना एक सीएसआरएफ हमला)। यदि आपका एपीआई क्रॉस-डोमेन है, और आप ब्राउज़र-से-सर्वर अनुरोध कर रहे हैं, तो जेडब्ल्यूटी कोड में कहीं भी है (चाहे वह प्रारंभिक स्थिति हो, या स्थानीय स्टोरेज)। यदि आप एक्सियोस का उपयोग करते हैं, तो हो सकता है कि आपने वैश्विक डिफ़ॉल्ट भी सेट किया हो, जहां हमलावर को केवल एक्सियोस अनुरोध करने की आवश्यकता होती है और यहां तक ​​​​कि ऑथ के बारे में भी चिंता नहीं होती है।

इसके अलावा, आप वास्तव में सीएसआरएफ के बारे में बात किए बिना एक्सएसएस के बारे में बात नहीं कर सकते; जहां प्रामाणिक कुकीज़ को विशेष रूप से लक्षित किया जाता है। यहां तक ​​कि एक रिवर्स प्रॉक्सी सेटअप के साथ, एक सीएसआरएफ हमला हमलावर को आपके एपीआई के खिलाफ प्रमाणित अनुरोधों को निष्पादित करने की अनुमति देगा।

बीटीडब्ल्यू, सिर्फ इसलिए कि आपने जेडब्ल्यूटी को कुकी में रखा है (कहने के लिए, यह जानना कि उपयोगकर्ता लॉग इन है या नहीं), इसका मतलब यह नहीं है कि आपको क्रॉस-डोमेन सर्वर-टू- के लिए कुकी वैल्यू (जैसे जेडब्ल्यूटी) का उपयोग करने से रोक दिया गया है। पेज लोड पर एपीआई-सर्वर एक्सेस (जो रिवर्स प्रॉक्सी परिदृश्य के लिए भी काम करता है)। न ही आप हैं या प्रारंभिक अवस्था में JWT पास करने से और साथ ही ब्राउज़र-से-एपीआई-सर्वर अनुरोधों के लिए भी आपको रोका नहीं गया है। वे परस्पर अनन्य नहीं हैं।

एक तरफ के रूप में, मुझे "स्टेटलेस" जेडब्ल्यूटी का विचार अधिकांश उपयोग-मामलों के लिए आवेदन में ओवररेटेड और सीमित दोनों का विचार मिलता है। उदाहरण के लिए:

• संसाधन आधारित / गतिशील अनुमतियाँ (उदाहरण के लिए न केवल " can edit Post ", बल्कि " can edit Post:1634 ")।
• क्या होगा यदि उपयोगकर्ता का खाता अवरुद्ध / हटा दिया गया है?
• उनकी मासिक सदस्यता का भुगतान नहीं किया है; कौन सी थ्रॉटल कार्यक्षमता?
• टोकन को ब्लैकलिस्ट किया गया (प्रति ऊपर)?

आप वह सब JWT में बेक नहीं कर रहे हैं, जिसका अर्थ है कि आपको पता लगाने के लिए डोमेन लेयर (यानी डेटाबेस) में डुबकी लगानी होगी। आपने अभी-अभी संसाधन लोड किया है, इसलिए इसे वहीं रख सकते हैं जहाँ बाकी ऐप इसे प्राप्त कर सकते हैं, और अब आपके पास राज्य है। मुझे यह सोचना वास्तव में मूर्खतापूर्ण लगता है कि विषय के बारे में आपको जो कुछ भी जानने की जरूरत है उसे टोकन में बेक किया जाएगा; एक साथ इसे ज्यादातर गुमनाम और हल्का रखते हुए। बहुत अधिक पचाए बिना, अंतर-सेवा संचार में "स्टेटलेस" अनुरोधों के लिए एक तर्क है, लेकिन यहां तक ​​​​कि मुझे अव्यावहारिक लगता है (कम से कम यह बेकिंग की अवधारणा से संबंधित है जिसे आपको जेडब्ल्यूटी में विषय के बारे में जानने की आवश्यकता है) .. .

इस बीच उपलब्ध ओथ प्रमाणीकरण रणनीतियाँ (बोल्ड में नई):

• स्थानीय (उपयोगकर्ता नाम/ईमेल/पासवर्ड)
• फेसबुक
• गूगल
• अतिथि
• पैट्रियन
• ट्विटर
• Authy (Twilio) - एसएमएस के माध्यम से पासवर्ड रहित

@jaredpalmer आपने लिखा
Php की तरह, Next की परमाणु इकाई पृष्ठ है। सबसे अच्छी विशेषताओं में से एक यह है कि यह आलसी प्रत्येक पृष्ठ को केवल तभी लोड करता है जब उसका अनुरोध किया जाता है। क्लाइंट-साइड केवल ऑथ के साथ लेकिन सर्वर-रेंडरिंग के साथ, उस संरक्षित पृष्ठ के लिए जेएस वास्तव में ब्राउज़र द्वारा डाउनलोड किया जाता है। भविष्य में जब नेक्स्ट सर्वर वर्कफ्लो जोड़ता है, तो उम्मीद है कि आप इसे पूरी तरह से रोकने के लिए सर्वर पर रेंडर और रीडायरेक्ट को ब्लॉक करने में सक्षम होंगे। इसके लिए कुकीज़, सत्र और AFAIK सत्र स्टोर की आवश्यकता होगी, लेकिन यह इस तरह के हाइब्रिड ऐप्स करने की लागत है।

हम 2 साल बाद हैं। क्या संरक्षित पृष्ठों के लिए जेएस लोड करने से रोकने के लिए कोई सर्वर वर्कफ़्लो है?
@timneutkens शायद दूसरे क्षेत्र में संरक्षित सामग्री डाल रहे हैं?
मैं सुरक्षित सामग्री तक पहुंच को पूरी तरह से कैसे रोकूं?

@lishine आपके पास अपने पृष्ठ के getInitialProps में एक ServerResponse है - आप आसानी से किसी अनपेक्षित व्यक्ति को पुनर्निर्देशित कर सकते हैं।

क्या Redux के साथ auth का कोई उदाहरण है?

क्या Redux के साथ auth का कोई उदाहरण है?

आप इस उदाहरण को आजमा सकते हैं जो रेडक्स का उपयोग कर रहा है, और जांचें कि यह आपके लिए काम करता है या नहीं ...
आप इसे इस विषय में कहीं पा सकते हैं, लेकिन यदि आप इसे नहीं पा सकते हैं, तो यह यहाँ है:
https://github.com/alan2207/nextjs-jwt-authentication

मुझे लगता है कि सर्वर साइड एपीआई कॉल परिणामों का उपयोग करते समय यह अधिक जटिल समस्या है, क्योंकि वर्चुअल डोम लॉगआउट-लॉगिन कार्रवाई के बाद पुराने परिणामों का उपयोग करता है। मैं समाधान के बारे में सोच रहा हूँ

_संपादित_
और यहाँ मेरा जवाब redux-अवलोकन योग्य के साथ है

|पक्ष|प्रामाणिक|TODO|
|---|---|---|
|सर्वर|सच|प्रारंभिक डेटा प्राप्त करें (अनुरोध कुकी प्रॉक्सी के साथ)।|
|सर्वर|झूठा|लॉगिन पेज दिखाएँ, और लॉगिन करने के बाद डेटा प्राप्त करें||
|क्लाइंट|सच|प्रारंभिक डेटा प्राप्त करें||
|क्लाइंट|गलत|लॉगिन पेज दिखाएँ, और लॉगिन करने के बाद डेटा प्राप्त करें। (यह तभी होता है जब सत्र पृष्ठ दर पृष्ठ स्थानांतरण में समाप्त हो जाता है)|

  static async getInitialProps({ store, query: { rowsPerPage, pageIndex }, req, auth }) {
    store.dispatch(TemporaryStoryActions.initPageState());

    const isAuthenticated = () => req ? req.isAuthenticated()
      : store.getState().auth.isAuthenticated;

    if (isAuthenticated()) {
      // fetch initial data
      const TemporaryStoryApiProxy = withCookieProxy(req, TemporaryStoryApi);
      await TemporaryStoryApiProxy.fetchTemporaryStories({
        rowsPerPage: rowsPerPage || 15,
        pageIndex: pageIndex || 0,                                                                                                                                  }).then(json => {
        store.dispatch(TemporaryStoryActions.loadTemporaryStories(
          json.rowsPerPage, json.pageIndex, json.count, json.rows));
      }).catch(error => {
        if (error.response && error.response.status === 403) {
          store.dispatch(AuthActions.initState(false, null));
          return;
        }
        throw error;
      });
    }

    if (!isAuthenticated()) {
      // => if client side fetch failed with 403, isAuthenticated() turns off to false
      // register logined action for client side login succeeded
      const reloadAction = TemporaryStoryActions.fetchTemporaryStories({
        rowsPerPage: rowsPerPage || 15,
        pageIndex: pageIndex || 0,
      });
      store.dispatch(AuthActions.addLoginedAction(reloadAction));
    }

    return {
      ...store.getState(),
    }                                                                                                                                                           }                                                                                             }

export const withLogin = Page => class SecurePage extends React.Component {
  static async getInitialProps (ctx) {
    if (ctx.req && ctx.store) {
      // server side
      const isAuthenticated = ctx.req.isAuthenticated();
      const { user } = ctx.req;
      ctx.store.dispatch(AuthActions.initState(isAuthenticated, user));
    }
    return Page.getInitialProps && await Page.getInitialProps(ctx)
  }

  render () {
    const { auth } = this.props;
    return auth.isAuthenticated ? <Page {...this.props} /> : <LoginPage />
  }                                                                                                                                                           }

// when [front-end server] => [api server]
// on Server Side Rendering,
// needs to proxy Cookies which sent to Next.js page request
export const withCookieProxy = (req, targetApi) => {
  if (!req) {
    return targetApi;
  }
  targetApi.client.interceptors.request.use(config => {
    const cookieString = Object.keys(req.cookies).map(key => `${key}=${req.cookies[key]}`).join('; ');
    const headers = {
      ...(config.headers || {}),
      Cookie: cookieString,
    };
    return {
      ...config,
      headers: headers,
    };
  }, error => {
    return Promise.reject(error);
  });
  return targetApi;
};

const loginEpic = (action$, state$) => action$.pipe(
  ofType(AuthActionTypes.login),
  mergeMap(action => {
    const email = action.payload.email;
    const password = action.payload.password;
    return from(AuthApi.login(email, password))
      .mergeMap(json => {
        const user = json.user;
        const loginedActions = state$.value.auth.loginedActions;
        const successActions = [
          AuthActions.removeAllLoginedActions(),
          ...loginedActions,
          AuthActions.loginSuccess(user.id, user.name, user.last_login_date),
        ];
        return from(successActions);
      }).pipe(catchError(error => {
        return of$(AuthActions.loginFail(error));
      }));
  }));

जटिल लगता है जब कुछ सरल होगा, की तर्ज पर:

export const withAuthSync = WrappedComponent => class extends Component {
  componentDidMount() {
    window.addEventListener('storage', this.syncLogout);
  }

  componentWillUnmount() {
    window.removeEventListener('storage', this.syncLogout);
    window.localStorage.removeItem('logout');
  }

    syncLogout = (event) => {
      if (event.key === 'logout') {
        console.log('logged out from storage!');
        window.location.reload();
      }
    };

    render() {
      return <WrappedComponent {...this.props} />;
    }
};

इस उदाहरण को Next.js 8 के भाग के रूप में मिला दिया गया था
https://github.com/zeit/next.js/tree/canary/examples/with-cookie-auth

@timneutkens लिंक के लिए धन्यवाद।

https://github.com/zeit/next.js/blob/canary/examples/with-cookie-auth/www/utils/auth.js#L26 -L34 ... को देखते हुए किसी प्रकार का नहीं होना चाहिए चेक के बाद auth() को कॉल किया गया था?

कुकी के बिना उदाहरण का परीक्षण करने से Profile.getInitialProps() कहा जा रहा है, जबकि मैंने सोचा था कि रीडायरेक्ट अधिक "प्रारंभिक प्रोप" प्राप्त करने की कोशिश करने से पहले होगा ...

मैंने यहां एक उदाहरण बनाया है जिसमें सर्वर-साइड प्री-रेंडरिंग + प्रमाणीकरण w/अपोलो है

https://github.com/HorizonShadow/apolo-next-now-test

कृपया ध्यान रखें कि OWASP सुरक्षा दिशानिर्देश स्थानीय संग्रहण में JWT टोकन को संग्रहीत करने के विरुद्ध अनुशंसा करते हैं, अर्थात "इन ऑब्जेक्ट्स में सभी डेटा को चुराने के लिए एक एकल क्रॉस साइट स्क्रिप्टिंग का उपयोग किया जा सकता है, इसलिए फिर से स्थानीय संग्रहण में संवेदनशील जानकारी संग्रहीत न करने की अनुशंसा की जाती है।"

यहाँ Auth0 है: टोकन और टॉम एबॉट को कहाँ स्टोर करें: अपने JWTs को कहाँ स्टोर करें - कुकीज़ बनाम HTML5 वेब स्टोरेज ।

यहाँ Nuxt.js + Express.js प्रॉक्सी सर्वर + Django बैकएंड के साथ एक उदाहरण दिया गया है। जहां एक्सप्रेस सर्वर का उपयोग वास्तविक बैकएंड के लिए प्रमाणीकरण अनुरोध को प्रॉक्सी करने के लिए किया जाता है और कुकी में जेडब्ल्यूटी टोकन भंडारण का उपयोग करते समय सीएसआरएफ सुरक्षा को संभाल रहा है (टोकन की लंबाई पर कुछ प्रतिबंध लगाता है/जेडब्ल्यूटी टोकन में कितनी जानकारी संग्रहीत की जा सकती है): https:/ /github.com/danjac/nuxt-python-secure-example

@timneutkens मुझे कुकी से SSR कस्टम रेडक्स मिडलवेयर में टोकन भेजने के तरीके के बारे में कुछ दस्तावेज़ चाहिए। मुझे _app.js के अंदर कुकीज़ मिल रही हैं। लेकिन मैं इसे customApimiddleware पर कैसे पास करूं। जहां मैंने फ़ेच अनुरोध लिखा है। धन्यवाद

मैंने Next.js प्रमाणीकरण/उपयोगकर्ता खातों पर एक मध्यम लेख लिखा था।
यह लगभग दो वर्षों के खाली समय के विकास और सोच से एक व्यापक ट्यूटोरियल और मेरा ब्रेनडंप है (इस मुद्दे पर मेरी पहली टिप्पणी फरवरी 2017 से है)।

https://medium.com/the-ideal-system/user-accounts-with-next-js-an-extensive-tutorial-6831cdaed16b

मुझे लगता है कि nextj.js ऐप में प्रमाणीकरण को संभालने के लिए यह सबसे अच्छे ट्यूटोरियल में से एक है। मैंने स्थानीय स्टोरेज (एक्सएसएस) में टोकन स्टोर करने, कुकीज़ में टोकन स्टोर करने (सीएसआरएफ को संभालने के बिना), और ब्राउज़र से कुकीज़ में टोकन स्टोर करने जैसी चीजें देखी हैं (एक्सएसएस और सीएसआरएफ दोनों कमजोर)।

मुझे वास्तव में रिवर्स प्रॉक्सी के साथ आपका समाधान पसंद है और विभिन्न सेवाओं के बीच सत्र जानकारी साझा करना। मैं वास्तव में next.js ऐप के लिए एक कस्टम सर्वर नहीं बनाना चाहता, लेकिन मुझे लगता है कि यह सत्रों को संभालने और सीएसआरएफ को रोकने (और शायद रिवर्स प्रॉक्सी जोड़ने) दोनों के लिए सबसे सरल तरीका है। मैं एक मोनोलिथ प्रोजेक्ट भी बना सकता हूं (दोनों ऐप को प्रस्तुत करने और डीबी ऑपरेशंस इत्यादि को संभालने के लिए)।

मैंने देखा है कि कुछ लोग (ZEIT सहित) API को स्टेटलेस रखते हैं और next.js ऐप को सत्र को संभालने देते हैं। यह एपीआई को टोकन पास करता है। लेकिन सत्रों के साथ जाने से चीजें थोड़ी अधिक तंग और कम जटिल हो जाती हैं।

next.js के लिए एक पूर्ण प्रमाणीकरण उदाहरण रखना वास्तव में एक बेहतर बात होगी। बाहरी एपीआई के लिए प्रमाणीकरण जैसी चीजों के साथ, सत्र को next.js ऐप में रखना, सेवाओं के बीच सत्र साझा करना या उन्हें टोकन देना, और टोकन की समय सीमा समाप्त होने पर उन्हें ताज़ा करना भी। (बहुत से लोग JWTs के बारे में बहुत कुछ लिखते हैं और बस उन्हें अपने ट्यूटोरियल में उपयोग करते हैं, लेकिन वे ज्यादातर उन्हें समाप्त भी नहीं करते हैं या उन्हें रीफ्रेश भी नहीं करते हैं।)

वैसे भी, आपने इस विषय पर सबसे संपूर्ण ट्यूटोरियल में से एक लिखा है। तो धन्यवाद!

मैं वास्तव में आशा करता हूं कि बहुत अधिक पूर्ण और स्पष्ट उदाहरण और दस्तावेज होंगे।

next.js के लिए एक पूर्ण प्रमाणीकरण उदाहरण रखना वास्तव में एक बेहतर बात होगी। बाहरी एपीआई के लिए प्रमाणीकरण जैसी चीजों के साथ, सत्र को next.js ऐप में रखना, सेवाओं के बीच सत्र साझा करना या उन्हें टोकन देना, और टोकन की समय सीमा समाप्त होने पर उन्हें ताज़ा करना भी। (बहुत से लोग JWTs के बारे में बहुत कुछ लिखते हैं और बस उन्हें अपने ट्यूटोरियल में उपयोग करते हैं, लेकिन वे ज्यादातर उन्हें समाप्त भी नहीं करते हैं या उन्हें रीफ्रेश भी नहीं करते हैं।)

मैं भी, एक नुकसान में हूं कि किस दृष्टिकोण को चुनना है।
लेख के लिंक के लिए बहुत-बहुत धन्यवाद।
वर्तमान में, आपने किन कार्यान्वयनों पर समझौता किया है?
क्या आपको अगले v9.3+ के लिए एक व्यापक प्राधिकरण उदाहरण मिला है?

Auth0 का नया कुकी आधारित दृष्टिकोण देखने लायक है
(बेशक यह एक विशेष पहचान प्रदाता के लिए है, लेकिन दृष्टिकोण देखने के लिए उपयोगी हो सकता है)
https://github.com/auth0/nextjs-auth0

• वास्तव में अच्छा है कि आप नेक्स्टज के एपीआई मार्गों (यहां तक ​​​​कि एक गतिशील मार्ग के माध्यम से) के माध्यम से एपीआई अनुरोधों को "प्रॉक्सी" कर सकते हैं।
• फिर आपको क्लाइंट साइड पर एक्सेस टोकन आदि को उजागर करने की आवश्यकता नहीं है (क्योंकि नेक्स्टज एपीआई रूट केवल सर्वर साइड को निष्पादित करते हैं), सर्वर साइड एक गुप्त के साथ auth0 लाइब्रेरी और कुकी के माध्यम से एक्सेस टोकन आदि प्राप्त कर सकता है।
• आपका क्लाइंट साइड कोड आपके नेक्स्टज एपीआई मार्गों को कॉल करेगा, और एपीआई मार्ग तब वास्तविक एपीआई अनुरोध करेगा

ध्यान रखें कि वे कहते हैं कि यह दृष्टिकोण रीडमी में "प्रयोगात्मक" है

Auth0 का नया कुकी आधारित दृष्टिकोण देखने लायक है
(बेशक यह एक विशेष पहचान प्रदाता के लिए है, लेकिन दृष्टिकोण देखने के लिए उपयोगी हो सकता है)
https://github.com/auth0/nextjs-auth0

• वास्तव में अच्छा है कि आप नेक्स्टज के एपीआई मार्गों (यहां तक ​​​​कि एक गतिशील मार्ग के माध्यम से) के माध्यम से एपीआई अनुरोधों को "प्रॉक्सी" कर सकते हैं।
• फिर आपको क्लाइंट साइड पर एक्सेस टोकन आदि को उजागर करने की आवश्यकता नहीं है (क्योंकि नेक्स्टज एपीआई रूट केवल सर्वर साइड को निष्पादित करते हैं), सर्वर साइड एक गुप्त के साथ auth0 लाइब्रेरी और कुकी के माध्यम से एक्सेस टोकन आदि प्राप्त कर सकता है।
• आपका क्लाइंट साइड कोड आपके नेक्स्टज एपीआई मार्गों को कॉल करेगा, और एपीआई मार्ग तब वास्तविक एपीआई अनुरोध करेगा

ध्यान रखें कि वे कहते हैं कि यह दृष्टिकोण रीडमी में "प्रयोगात्मक" है

यह लेख बहुत मददगार है और इसमें कई अलग-अलग आर्किटेक्चर शामिल हैं।
https://auth0.com/blog/ultimate-guide-nextjs-authentication-auth0/

एपीआई मार्गों को प्रॉक्सी के रूप में उपयोग करना, एपीआई मार्गों के माध्यम से लॉगिन/लॉगआउट करना, एपीआई से टोकन प्राप्त करना, इसे एचटीपीओनली कुकी के रूप में सेट करना एक ठोस दृष्टिकोण है जो मुझे लगता है।
एक चिंता सीएसआरएफ हो सकती है, लेकिन आप आसानी से csrf npm पैकेज के साथ कुछ समाधान बना सकते हैं ( csurf , लेकिन वह भी काम कर सकता है)।

@onderonur , auth0 लेख के लिए धन्यवाद।
अर्थात्, वर्तमान में next.js के साथ शुद्ध jwt पर कार्यान्वयन का एक विश्वसनीय या कम से कम न्यूनतम उदाहरण है?
मैं कुकीज़ के साथ एक उन्नत परत नहीं बनाना चाहता और उन्हें स्थापित करना चाहता हूं। सीएसआर एप्लिकेशन में, हमने बस टोकन को लोकलस्टोरेज में स्टोर किया और अनुरोध के साथ भेज दिया।

@onderonur , auth0 लेख के लिए धन्यवाद।
अर्थात्, वर्तमान में next.js के साथ शुद्ध jwt पर कार्यान्वयन का एक विश्वसनीय या कम से कम न्यूनतम उदाहरण है?
मैं कुकीज़ के साथ एक उन्नत परत नहीं बनाना चाहता और उन्हें स्थापित करना चाहता हूं। सीएसआर एप्लिकेशन में, हमने बस टोकन को लोकलस्टोरेज में स्टोर किया और अनुरोध के साथ भेज दिया।

मैंने इस विधि का उपयोग अपने रेपो में से एक के लिए किया है लेकिन यह अभी भी मसौदे में है, इसलिए उन्हें स्वयं परीक्षण करना सुनिश्चित करें :)
https://github.com/onderonur/post-gallery
वास्तव में "कुकी परत" एक उन्नत चीज नहीं है। /api/login एपीआई मार्ग के माध्यम से बस अपने एपीआई के लॉगिन एंडपॉइंट को कॉल करें और यदि अनुरोध सफल होता है, तो टोकन को httpOnly कुकी में सेट करें।
आप ठीक उसी कार्यान्वयन के लिए मेरे रेपो की जांच कर सकते हैं।

एक अन्य विकल्प है (यदि आप स्थानीय भंडारण में टोकन सेट करने के समान प्रवाह चाहते हैं), तो आप js-cookie npm पैकेज का उपयोग कर सकते हैं, क्लाइंट-साइड अनुरोध के साथ अपने लॉगिन एंडपॉइंट को कॉल कर सकते हैं, यदि यह वापस आता है तो समाप्त करें एक टोकन, इसे कुकी में सेट करें। और जब आप अनुरोध करते हैं (अक्षीय इंटरसेप्टर आदि के माध्यम से) कुकी मान पढ़ें और अनुरोध शीर्षलेख के रूप में इसे अपने एपीआई में पास करें। मैंने इस दृष्टिकोण का उपयोग करते हुए बहुत सारे (और यहां तक ​​कि कुछ लोकप्रिय) एप्लिकेशन देखे हैं। लेकिन यह थोड़ा असुरक्षित है। क्योंकि आप ब्राउज़र में httpOnly कुकीज सेट नहीं कर सकते हैं। तो, जावास्क्रिप्ट आपकी टोकन कुकी को पढ़ने में सक्षम होगा। इस प्रकार, XSS भेद्यता होगी।

इसकी सराहना करें कि यह एक पुराना धागा है (और सामान्य रूप से एक लंबे समय तक चलने वाला विषय है) लेकिन अतिरिक्त संदर्भ या उदाहरण की तलाश करने वालों के लिए, हमने हाल ही में NextAuth.js v2 पर काम किया है। मैं इसका उल्लेख प्लग के रूप में इतना नहीं करता - यह एक ओपन सोर्स प्रोजेक्ट है और लोगों के एक समूह ने इसमें मदद की है - लेकिन यह उपयोग करने के लिए बहुत आसान है और कोड और दृष्टिकोण लोगों के संदर्भ के रूप में उपयोगी हो सकता है।

कुछ पृष्ठभूमि के लिए, जैसे नेक्स्टअथ v1, यह केवल हस्ताक्षरित, प्रीफ़िक्स्ड और एचटीटीपी कुकीज़ का उपयोग करता है, क्लाइंट साइड टोकन का उपयोग करने के सामान्य सुरक्षा नुकसान से बचता है।

NextAuth.js v2 Apple, Google, Facebook, Twitter, GitHub, Auth0, Okta, Slack, Discord और अन्य OAuth प्रदाताओं के साथ साइन इन करने का समर्थन करता है (यह 1.x और 2.x दोनों का समर्थन करता है)। आप इसका उपयोग MySQL, MariaDB, Postgres, MongoDB के साथ कर सकते हैं - या कोई डेटाबेस नहीं (100% सर्वर रहित समाधान के लिए केवल OAuth और JSON वेब टोकन)।

उपयोग बहुत सरल है, session() नामक एक सार्वभौमिक स्थिर विधि है और useSession() नामक एक रिएक्ट हुक जिसे आप घटक क्लाइंट साइड में उपयोग कर सकते हैं:

import { useSession } from 'next-auth/client'

export default () => {
  const [session, loading] = useSession()

  return <>
    {!loading && session && <p>Signed in as {session.user.name || session.user.email}.</p>}
    {!loading && !session && <p><a href="/api/auth/signin">Sign in here</a></p>}
  </>
}

यह Next.js 9.x और Serverless के लिए बनाया गया है, और इसमें Express या PassportJS जैसी निर्भरताएँ नहीं हैं। इसमें एक प्रमाणीकरण प्रदाता शामिल है जिसका उपयोग आप _app.js सभी पृष्ठों पर प्रमाणीकरण स्थिति को स्वचालित रूप से जोड़ने के लिए कर सकते हैं; यह क्लाइंट और सर्वर साइड रेंडरिंग दोनों के लिए काम करता है।

अधिक जानकारी के लिए, next-auth.js.org देखें या NPM पर auth@beta देखें ।

• होमपेज: https://next-auth.js.org
• डेमो: https://next-auth-example.now.sh
• एनपीएम: npm i next-auth@beta

यह अभी भी एक कार्य प्रगति पर है - हम अभी भी दस्तावेज़ीकरण और इवेंट मॉडल को पॉलिश कर रहे हैं - ~ ​​जून के मध्य की लक्ष्य रिलीज की तारीख के साथ।

इसकी सराहना करें कि यह एक पुराना धागा है (और सामान्य रूप से एक लंबे समय तक चलने वाला विषय है) लेकिन अतिरिक्त संदर्भ या उदाहरण की तलाश करने वालों के लिए, हमने हाल ही में NextAuth.js v2 पर काम किया है। मैं इसका उल्लेख प्लग के रूप में इतना नहीं करता - यह एक ओपन सोर्स प्रोजेक्ट है और लोगों के एक समूह ने इसमें मदद की है - लेकिन यह उपयोग करने के लिए बहुत आसान है और कोड और दृष्टिकोण लोगों के संदर्भ के रूप में उपयोगी हो सकता है।

कुछ पृष्ठभूमि के लिए, जैसे नेक्स्टअथ v1, यह केवल हस्ताक्षरित, प्रीफ़िक्स्ड और एचटीटीपी कुकीज़ का उपयोग करता है, क्लाइंट साइड टोकन का उपयोग करने के सामान्य सुरक्षा नुकसान से बचता है।

NextAuth.js v2 Apple, Google, Facebook, Twitter, GitHub, Auth0, Okta, Slack, Discord और अन्य OAuth प्रदाताओं के साथ साइन इन करने का समर्थन करता है (यह 1.x और 2.x दोनों का समर्थन करता है)। आप इसका उपयोग MySQL, MariaDB, Postgres, MongoDB के साथ कर सकते हैं - या कोई डेटाबेस नहीं (100% सर्वर रहित समाधान के लिए केवल OAuth और JSON वेब टोकन)।

उपयोग बहुत सरल है, session() नामक एक सार्वभौमिक स्थिर विधि है और useSession() नामक एक रिएक्ट हुक जिसे आप घटक क्लाइंट साइड में उपयोग कर सकते हैं:

import { useSession } from 'next-auth/client'

export default () => {
  const [session, loading] = useSession()

  return <>
    {!loading && session && <p>Signed in as {session.user.name || session.user.email}.</p>}
    {!loading && !session && <p><a href="/api/auth/signin">Sign in here</a></p>}
  </>
}

यह Next.js 9.x और Serverless के लिए बनाया गया है, और इसमें Express या PassportJS जैसी निर्भरताएँ नहीं हैं। इसमें एक प्रमाणीकरण प्रदाता शामिल है जिसका उपयोग आप _app.js सभी पृष्ठों पर प्रमाणीकरण स्थिति को स्वचालित रूप से जोड़ने के लिए कर सकते हैं; यह क्लाइंट और सर्वर साइड रेंडरिंग दोनों के लिए काम करता है।

अधिक जानकारी के लिए, next-auth.js.org देखें या NPM पर auth@beta देखें ।

• होमपेज: https://next-auth.js.org
• डेमो: https://next-auth-example.now.sh
• एनपीएम: npm i next-auth@beta

यह अभी भी एक कार्य प्रगति पर है - हम अभी भी दस्तावेज़ीकरण और इवेंट मॉडल को पॉलिश कर रहे हैं - ~ ​​जून के मध्य की लक्ष्य रिलीज की तारीख के साथ।

बढ़िया काम यह!
क्या इसका इस्तेमाल अकेले क्लाइंट साइड पर किया जा सकता है? उदाहरण के लिए, मेरे पास रेल एपीआई ऐप है - और क्लाइंट साइड के लिए अगले जेएस का उपयोग करें।