নোড.জেএস সহ নিরাপদ আরএসটি এপিআই কীভাবে প্রয়োগ করবেন

Question

আমি নোড.জেএস, এক্সপ্রেস এবং মংডোব দিয়ে একটি REST এপিআইয়ের পরিকল্পনা শুরু করি। এপিআই কোনও ওয়েবসাইটের জন্য (সরকারী এবং ব্যক্তিগত অঞ্চল) এবং সম্ভবত পরে একটি মোবাইল অ্যাপ্লিকেশন ডেটা সরবরাহ করে। অ্যাঙ্গুলারজেএস দিয়ে এই সীমানাটি তৈরি করা হবে।

কিছু দিনের জন্য আমি আরএসটি এপিআইগুলি সুরক্ষিত করার বিষয়ে অনেকগুলি পড়েছি, তবে আমি চূড়ান্ত সমাধান পাচ্ছি না। আমি যতদূর বুঝতে পেরেছি এটি একটি প্রাথমিক সুরক্ষা সরবরাহ করতে এইচটিটিপিএস ব্যবহার করা। তবে আমি কীভাবে সেই ব্যবহারের ক্ষেত্রে API টি সুরক্ষা দিতে পারি:

• কেবলমাত্র ওয়েবসাইট / অ্যাপ্লিকেশন / ব্যবহারকারীদের / ব্যবহারকারীদেরই ওয়েবসাইট / অ্যাপের সর্বজনীন ক্ষেত্রের ডেটা পাওয়ার অনুমতি রয়েছে

• কেবলমাত্র অনুমোদিত এবং অনুমোদিত ব্যবহারকারীদেরই ব্যক্তিগত অঞ্চল (এবং কেবলমাত্র ডেটা, যেখানে ব্যবহারকারী অনুমতি দিয়েছে) এর জন্য ডেটা পাওয়ার অনুমতি পায়

এই মুহুর্তে আমি কেবল সক্রিয় অধিবেশন ব্যবহারকারীদের এপিআই ব্যবহারের অনুমতি দেওয়ার বিষয়ে ভাবছি। ব্যবহারকারীদের অনুমোদনের জন্য আমি পাসপোর্ট ব্যবহার করব এবং অনুমতি নেওয়ার জন্য আমাকে নিজের জন্য কিছু বাস্তবায়ন করতে হবে। সবগুলি এইচটিটিপিএসের শীর্ষে।

কেউ কি কিছু সেরা অনুশীলন বা অভিজ্ঞতা প্রদান করতে পারেন? আমার "আর্কিটেকচার" এর কোনও অভাব আছে কি?

Comments

আমি অনুমান করছি যে API আপনি কেবলমাত্র সরবরাহ করা ফ্রন্টএন্ড থেকে ব্যবহার করতে পারবেন? সেক্ষেত্রে ব্যবহারকারী বৈধ কিনা তা নিশ্চিত করতে সেশনটি ব্যবহার করা ভাল সমাধানের মতো বলে মনে হচ্ছে। অনুমতিগুলির জন্য, আপনি নোড-ভূমিকাগুলি একবার দেখে নিতে পারেন ।

— রবার্টক্লেপ

আপনি এই জন্য অবশেষে কি করলেন? যে কোনও বয়লার প্লেট কোড (সার্ভার / মোবাইল অ্যাপ্লিকেশন ক্লায়েন্ট) আপনি ভাগ করতে পারেন?

— মোর্তেজা শাহরিয়ারি নিয়া

Answer 1

আপনি বর্ণিত একই সমস্যা আমার ছিল। আমি যে ওয়েবসাইটটি তৈরি করছি সেটিকে মোবাইল ফোন এবং ব্রাউজার থেকে অ্যাক্সেস করা যেতে পারে তাই ব্যবহারকারীদের সাইনআপ, লগইন এবং কিছু নির্দিষ্ট কাজ করার অনুমতি দেওয়ার জন্য আমার এপিআই দরকার। তদুপরি, আমার স্কেলাবিলিটি সমর্থন করতে হবে, একই কোডটি বিভিন্ন প্রক্রিয়া / মেশিনে চলছে।

কারণ ব্যবহারকারীরা আপনার এপিআই সুরক্ষিত করার জন্য সংস্থানগুলি তৈরি করতে পারে (ওরফে পোষ্ট / পুট ক্রিয়া)। আপনি ওআউথ ব্যবহার করতে পারেন বা আপনি নিজের সমাধান তৈরি করতে পারেন তবে মনে রাখবেন যে পাসওয়ার্ডটি আবিষ্কার করা সত্যিই সহজ the মূল ধারণাটি হ'ল ব্যবহারকারীরা ব্যবহারকারীর নাম, পাসওয়ার্ড এবং একটি টোকেন ব্যবহার করেন যা এপিটিোকেন। এই এপিটোকেন নোড- ইউইড ব্যবহার করে উত্পন্ন করা যায় এবং pbkdf2 ব্যবহার করে পাসওয়ার্ডটি হ্যাশ করা যায়

তারপরে, আপনার কোথাও সেশনটি সংরক্ষণ করা দরকার। যদি আপনি এটিকে স্মৃতিতে একটি সরল বস্তুতে সংরক্ষণ করেন, আপনি যদি সার্ভারটি মেরে ফেলে এবং পুনরায় বুট করেন তবে সেশনটি নষ্ট হয়ে যাবে। এছাড়াও, এটি স্কেলযোগ্য নয়। আপনি যদি মেশিনগুলির মধ্যে ভারসাম্য লোড করতে হ্যাপ্রোক্সি ব্যবহার করেন বা আপনি যদি কেবল শ্রমিক ব্যবহার করেন তবে এই সেশন স্টেটটি একটি একক প্রক্রিয়াতে সংরক্ষণ করা হবে তাই যদি একই ব্যবহারকারীর অন্য কোনও প্রক্রিয়া / মেশিনে পুনঃনির্দেশ করা হয় তবে এটি আবার প্রমাণীকরণের প্রয়োজন হবে। সুতরাং আপনার একটি সাধারণ জায়গায় সেশনটি সংরক্ষণ করতে হবে। এটি সাধারণত redis ব্যবহার করে করা হয়।

যখন ব্যবহারকারী প্রমাণিত হয় (ব্যবহারকারীর + পাসওয়ার্ড + অ্যাপিটোকেন) সেশনের জন্য অন্য একটি টোকেন উত্পন্ন করে, ওরফে অ্যাক্সেসটোকেন। আবার নোড-ইউইড সহ। ব্যবহারকারীকে অ্যাক্সেসস্টোকেন এবং ব্যবহারকারীকে প্রেরণ করুন। ইউজারিড (কী) এবং অ্যাকসেসটোকেন (মান) পুনরায় redis এ সংরক্ষণ হয় এবং সময়ের মেয়াদ শেষ হয়, যেমন 1 ঘন্টা।

এখন, প্রতিবার ব্যবহারকারী যখন এপিআই ব্যবহার করে কোনও অপারেশন করে তখন ইউজারিড এবং অ্যাকসেসটোকেন প্রেরণ করতে হবে।

আপনি যদি বাকী এপিআই ব্যবহার করে ব্যবহারকারীদের সাইন আপ করার অনুমতি দেন তবে আপনাকে প্রশাসক এপিটোকেন দিয়ে একটি অ্যাডমিন অ্যাকাউন্ট তৈরি করতে হবে এবং সেগুলি মোবাইল অ্যাপে সংরক্ষণ করতে হবে (এনক্রিপ্ট করে ব্যবহারকারীর নাম + পাসওয়ার্ড + অ্যাপিটোকেন) কারণ যখন নতুন ব্যবহারকারীদের এপিটোকেন থাকবে না তারা সাইন আপ।

ওয়েবেও এই এপিআই ব্যবহার করে তবে আপনাকে এপিটোকেন ব্যবহার করার দরকার নেই। আপনি রেডিস স্টোরের সাহায্যে এক্সপ্রেস ব্যবহার করতে পারেন বা উপরে বর্ণিত একই কৌশল ব্যবহার করতে পারেন তবে এপিটোকেন চেককে বাইপাস করে এবং কুকিতে ইউজারিড + অ্যাকসেসটোকেন ব্যবহারকারীর কাছে ফিরে আসতে পারেন।

আপনার যদি ব্যক্তিগত ক্ষেত্রগুলি অনুমোদিত ব্যবহারকারীদের সাথে অনুমোদনের সময় ব্যবহারকারীর নাম তুলনা করে। আপনি ব্যবহারকারীদের ভূমিকাও প্রয়োগ করতে পারেন।

সারসংক্ষেপ:

এপিটোকেন ব্যতীত বিকল্প হ'ল এইচটিটিপিএস ব্যবহার করা এবং অনুমোদনের শিরোনামে ব্যবহারকারীর নাম এবং পাসওয়ার্ড প্রেরণ করা এবং ইউজারনেমটি পুনরায় redes করাতে হবে।

Comments

আমি মঙ্গডবও ব্যবহার করি তবে আপনি রেডিস (অ্যাটমিক অপারেশনগুলি ব্যবহার করুন) ব্যবহার করে সেশনটি (অ্যাক্সেসটোকেন) সংরক্ষণ করলে এটি পরিচালনা করা বেশ সহজ। এপিটোকেন সার্ভারে উত্পন্ন হয় যখন ব্যবহারকারী কোনও অ্যাকাউন্ট তৈরি করে তা ব্যবহারকারীকে ফেরত পাঠায়। তারপরে, ব্যবহারকারী যখন প্রমাণীকরণ করতে চান তখন অবশ্যই এটি ব্যবহারকারীর নাম + পাসওয়ার্ড + এপিটোকেন (এগুলি HTTP শৃঙ্খলে রেখে দিন) প্রেরণ করতে হবে। মনে রাখবেন যে এইচটিটিপি দেহটি এনক্রিপ্ট করে না যাতে পাসওয়ার্ড এবং এপিটোকেন শুকানো যায়। এটি যদি আপনার জন্য উদ্বেগজনক হয় তবে এইচটিটিপিএস ব্যবহার করুন।

— গ্যাব্রিয়েল লালামাস

একটি ব্যবহার করার apitokenকি লাভ? এটি কি একটি "মাধ্যমিক" পাসওয়ার্ড?

— সালভাতোরালব

@ দ্য ব্রোনাক্স এপিটোকেনের দুটি ব্যবহারের মামলা রয়েছে: ১) একটি এপিটোকেন দিয়ে আপনি আপনার সিস্টেমে ব্যবহারকারীদের অ্যাক্সেস নিয়ন্ত্রণ করতে পারেন এবং আপনি প্রতিটি ব্যবহারকারীর পরিসংখ্যানটি নিরীক্ষণ ও নির্মাণ করতে পারেন। 2) এটি একটি অতিরিক্ত সুরক্ষা ব্যবস্থা, একটি "মাধ্যমিক" পাসওয়ার্ড।

— গ্যাব্রিয়েল লালামাস

সাফল্যরূপী প্রমাণীকরণের পরে আপনি বার বার কেন ইউজার আইডি প্রেরণ করবেন। টোকেনটি কেবলমাত্র এপিআই কলগুলি করার জন্য আপনার কেবল গোপনীয় হওয়া উচিত।

— এক্সেল নাপোলিটানো

টোকেনের আইডিয়া - ব্যবহারকারীর ক্রিয়াকলাপ ট্র্যাক করার জন্য এটি অপব্যবহারের পাশাপাশি - এটি হ'ল কোনও ব্যবহারকারীর আদর্শভাবে কোনও অ্যাপ্লিকেশন ব্যবহারের জন্য কোনও ব্যবহারকারীর নাম এবং পাসওয়ার্ডের প্রয়োজন হয় না: টোকেনটি অনন্য অ্যাক্সেস কী। এটি ব্যবহারকারীদের কোনও অ্যাপ্লিকেশনকে প্রভাবিত করে তবে যে কোনও সময়ে কোনও কী বাদ দিতে পারে। ওয়েবসার্চিসের জন্য একটি টোকন বেশ অযৌক্তিক - সেজন্য একটি সেশনের প্রাথমিক লগইনটি সেই জায়গা যেখানে ব্যবহারকারী সেই টোকেন পান - একটি "নিয়মিত" ক্লায়েন্টের জন্য, একটি টোকেন কোনও সমস্যা নয়: একবার এটি প্রবেশ করুন এবং আপনি প্রায় শেষ হয়ে গেছেন ;)

— এক্সেল নাপোলিটানো

Answer 2

আমি গৃহীত প্রশ্নের উত্তর অনুসারে (আমি আশা করি) উত্থাপিত প্রশ্নের কাঠামোগত সমাধান হিসাবে এই কোডটি অবদান রাখতে চাই। (আপনি খুব সহজেই এটি কাস্টমাইজ করতে পারেন)।

// ------------------------------------------------------
// server.js 

// .......................................................
// requires
var fs = require('fs');
var express = require('express'); 
var myBusinessLogic = require('../businessLogic/businessLogic.js');

// .......................................................
// security options

/*
1. Generate a self-signed certificate-key pair
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out certificate.pem

2. Import them to a keystore (some programs use a keystore)
keytool -importcert -file certificate.pem -keystore my.keystore
*/

var securityOptions = {
    key: fs.readFileSync('key.pem'),
    cert: fs.readFileSync('certificate.pem'),
    requestCert: true
};

// .......................................................
// create the secure server (HTTPS)

var app = express();
var secureServer = require('https').createServer(securityOptions, app);

// ------------------------------------------------------
// helper functions for auth

// .............................................
// true if req == GET /login 

function isGETLogin (req) {
    if (req.path != "/login") { return false; }
    if ( req.method != "GET" ) { return false; }
    return true;
} // ()

// .............................................
// your auth policy  here:
// true if req does have permissions
// (you may check here permissions and roles 
//  allowed to access the REST action depending
//  on the URI being accessed)

function reqHasPermission (req) {
    // decode req.accessToken, extract 
    // supposed fields there: userId:roleId:expiryTime
    // and check them

    // for the moment we do a very rigorous check
    if (req.headers.accessToken != "you-are-welcome") {
        return false;
    }
    return true;
} // ()

// ------------------------------------------------------
// install a function to transparently perform the auth check
// of incoming request, BEFORE they are actually invoked

app.use (function(req, res, next) {
    if (! isGETLogin (req) ) {
        if (! reqHasPermission (req) ){
            res.writeHead(401);  // unauthorized
            res.end();
            return; // don't call next()
        }
    } else {
        console.log (" * is a login request ");
    }
    next(); // continue processing the request
});

// ------------------------------------------------------
// copy everything in the req body to req.body

app.use (function(req, res, next) {
    var data='';
    req.setEncoding('utf8');
    req.on('data', function(chunk) { 
       data += chunk;
    });
    req.on('end', function() {
        req.body = data;
        next(); 
    });
});

// ------------------------------------------------------
// REST requests
// ------------------------------------------------------

// .......................................................
// authenticating method
// GET /login?user=xxx&password=yyy

app.get('/login', function(req, res){
    var user = req.query.user;
    var password = req.query.password;

    // rigorous auth check of user-passwrod
    if (user != "foobar" || password != "1234") {
        res.writeHead(403);  // forbidden
    } else {
        // OK: create an access token with fields user, role and expiry time, hash it
        // and put it on a response header field
        res.setHeader ('accessToken', "you-are-welcome");
        res.writeHead(200); 
    }
    res.end();
});

// .......................................................
// "regular" methods (just an example)
// newBook()
// PUT /book

app.put('/book', function (req,res){
    var bookData = JSON.parse (req.body);

    myBusinessLogic.newBook(bookData, function (err) {
        if (err) {
            res.writeHead(409);
            res.end();
            return;
        }
        // no error:
        res.writeHead(200);
        res.end();
    });
});

// .......................................................
// "main()"

secureServer.listen (8081);

এই সার্ভারটি কার্ল দিয়ে পরীক্ষা করা যেতে পারে:

echo "----   first: do login "
curl -v "https://localhost:8081/login?user=foobar&password=1234" --cacert certificate.pem

# now, in a real case, you should copy the accessToken received before, in the following request

echo "----  new book"
curl -X POST  -d '{"id": "12341324", "author": "Herman Melville", "title": "Moby-Dick"}' "https://localhost:8081/book" --cacert certificate.pem --header "accessToken: you-are-welcome" 

Comments

এই নমুনার জন্য ধন্যবাদ এটির খুব সহায়ক, তবে আমি এটি অনুসরণ করার চেষ্টা করি এবং আমি যখন এটি লগইন করতে সংযোগ করি তখন এটি: কার্ল: (51) এসএসএল: শংসাপত্র বিষয়বস্তু 'xxxx' লক্ষ্য হোস্টের নাম 'xxx.net' এর সাথে মেলে না।

— Https

Answer 3

আমি স্রেফ একটি নমুনা অ্যাপ্লিকেশন শেষ করেছি যা এটি একটি সুন্দর মৌলিক, তবে পরিষ্কার উপায়ে করে। এটি মংডোব সহ মঙ্গস ব্যবহার করে লেখক এবং ব্যবহারকারীদের পরিচালনার জন্য পাসপোর্ট সঞ্চয় করতে।

https://github.com/Khelldar/Angular-Express-Train-Seed

Comments

আপনি এপিআই সুরক্ষিত করতে কুকি ব্যবহার করছেন। আমি এটা সঠিক মনে করি না।

— ভিন্স ইউয়ান

Answer 4

এখানে এসইএস-তে REST লেখক নিদর্শন সম্পর্কে অনেক প্রশ্ন রয়েছে। এগুলি আপনার প্রশ্নের জন্য সবচেয়ে প্রাসঙ্গিক:

• আমার নোড.জেএস অ্যাপ্লিকেশনটির REST এপিআই সুরক্ষিত করছেন?
• বিশুদ্ধ প্রমাণীকরণ

মূলত আপনাকে এপিআই কী ব্যবহার করতে হবে (কীটি অননুমোদিত ব্যবহারকারীর দ্বারা কমপক্ষে নিরাপদ হিসাবে সুরক্ষিত), একটি অ্যাপ কী এবং টোকেন কম্বো (মাঝারি), বা একটি সম্পূর্ণ OAuth প্রয়োগকরণ (সর্বাধিক সুরক্ষিত) মধ্যে নির্বাচন করা দরকার।

Comments

আমি oauth 1.0 এবং oauth 2.0 সম্পর্কে প্রচুর পড়েছি এবং উভয় সংস্করণ খুব নিরাপদ বলে মনে হচ্ছে না। উইকিপিডিয়া লিখেছিল যে oauth 1.0 এ কিছু সুরক্ষা লিক। এছাড়াও আমি একটি নিবন্ধ পেয়েছি যে প্রায় একজন মূল বিকাশকারী দলকে বোকাউজ দেয় oauth 2.0 অসুরক্ষিত করা।

— tschiela

@tschiela আপনার এখানে উদ্ধৃত যে কোনও কিছুতে আপনার উল্লেখ যুক্ত করা উচিত।

— মাইকমেকানা

Answer 5

আপনি যদি নিজের অ্যাপ্লিকেশনটি সুরক্ষিত করতে চান তবে অবশ্যই আপনার অবশ্যই এইচটিটিপিএসের পরিবর্তে এইচটিটিপিএস ব্যবহার করে শুরু করা উচিত , এটি আপনার এবং ব্যবহারকারীদের মধ্যে একটি সুরক্ষিত চ্যানেল তৈরি করা নিশ্চিত করে যা ব্যবহারকারীদের কাছে পিছনে পাঠানো ডেটা স্নিগ্ধ করা রোধ করবে এবং ডেটা রাখতে সহায়তা করবে গোপনীয়তার বিনিময়

আপনি RESTful API গুলি সুরক্ষিত করতে JWTs (JSON ওয়েব টোকেন) ব্যবহার করতে পারেন , সার্ভার-সাইড সেশনের তুলনায় এর অনেক সুবিধা রয়েছে, সুবিধাগুলি মূলত:

1- আরও স্কেলযোগ্য, আপনার এপিআই সার্ভারগুলিতে প্রতিটি ব্যবহারকারীর জন্য সেশন বজায় রাখতে হবে না (যখন আপনার অনেক সেশন থাকে তখন এটি একটি বড় বোঝা হতে পারে)

২- জেডাব্লুটিটি স্ব-অন্তর্ভুক্ত থাকে এবং দাবী রাখে যা ব্যবহারকারীর ভূমিকা উদাহরণ হিসাবে বর্ণনা করে এবং তিনি কী কী অ্যাক্সেস করতে পারবেন এবং তারিখ এবং সমাপ্তির তারিখে জারি করতে পারবেন (এর পরে জেডব্লিউটি বৈধ হবে না)

3- লোড-ব্যালেন্সারগুলিকে হ্যান্ডেল করা সহজ এবং যদি আপনার একাধিক এপিআই সার্ভার থাকে কারণ আপনার সেশন ডেটা শেয়ার করতে হবে না বা সেশনটি একই সার্ভারে যাওয়ার জন্য সার্ভারটি কনফিগার করতে হবে না, যখনই কোনও জেডব্লিউটি-র কোনও অনুরোধ কোনও সার্ভারকে আঘাত করে তবে এটি প্রমাণীকরণযোগ্য হতে পারে & অনুমোদিত

4- আপনার ডিবিতে কম চাপের পাশাপাশি প্রতিটি অনুরোধের জন্য আপনাকে নিয়মিত সেশন আইডি এবং ডেটা সংগ্রহ করতে হবে না

5- আপনি জেডাব্লুটিটিতে স্বাক্ষর করার জন্য একটি শক্তিশালী কী ব্যবহার করলে জেডাব্লুটিগুলিতে কোনও হস্তক্ষেপ করা যাবে না, তাই আপনি ব্যবহারকারীর অধিবেশন যাচাই না করেই এবং অনুরোধের সাথে প্রেরিত জেডাব্লুটিটিতে যে দাবি রয়েছে তা বিশ্বাস করতে পারেন এবং তিনি অনুমোদিত কিনা তাও নয়। , আপনি কেবল জেডাব্লুটিটি পরীক্ষা করে দেখতে পারেন এবং তারপরে এই ব্যবহারকারী কে এবং কী করতে পারেন তা জানতে আপনি প্রস্তুত।

অনেক লাইব্রেরি বেশিরভাগ প্রোগ্রামিং ভাষায় JWTs তৈরি ও বৈধ করার সহজ উপায় সরবরাহ করে, উদাহরণস্বরূপ: নোড.জেএস- এ সর্বাধিক জনপ্রিয় একটি হল জসনওবটোকেন

যেহেতু বিশ্রাম API গুলি সাধারণত সার্ভার আড়ম্বরহীন রাখা, তাই JWTs যে ধারণার সঙ্গে বেশি সুসংগত প্রতিটি অনুরোধের অনুমোদন সঙ্গে পাঠানো হয় যে টোকেন স্বয়ংসম্পূর্ণ হয় লক্ষ্যে কাজ করে (JWT) সার্ভার সেশন যা করতে তুলনায় ব্যবহারকারী সেশন ট্র্যাক রাখতে না করেও সার্ভার স্টেটফুল যাতে এটি ব্যবহারকারীর এবং তার ভূমিকার কথা মনে রাখে তবে সেশনগুলিও ব্যাপকভাবে ব্যবহৃত হয় এবং তাদের পরামর্শ রয়েছে, যা আপনি চাইলে অনুসন্ধান করতে পারেন।

একটি গুরুত্বপূর্ণ বিষয় লক্ষণীয় হ'ল আপনাকে এইচটিটিপিএস ব্যবহার করে ক্লায়েন্টকে নিরাপদে জেডাব্লুটি সরবরাহ করতে হবে এবং এটি একটি নিরাপদ জায়গায় সংরক্ষণ করতে হবে (উদাহরণস্বরূপ স্থানীয় সঞ্চয়স্থান)।

আপনি এই লিঙ্কটি থেকে জেডব্লিউটি সম্পর্কে আরও শিখতে পারেন

Comments

আমি আপনার উত্তরটি পছন্দ করি যা পুরানো প্রশ্নটির সেরা আপডেট বলে মনে হচ্ছে। আমি একই বিষয়টিতে নিজেকে একটি অন্য প্রশ্ন জিজ্ঞাসা করেছি এবং আপনিও সহায়ক হতে পারেন। => Stackoverflow.com/questions/58076644/...

— pbonnefoi

ধন্যবাদ, আমি সাহায্য করতে পেরে আনন্দিত, আমি আপনার প্রশ্নের উত্তর পোস্ট করছি

— আহমেদ এলকৌসি

Answer 6

আপনি যদি নিজের ওয়েব অ্যাপ্লিকেশনটির একটি সম্পূর্ণ লকডাউন অঞ্চল রাখতে চান যা কেবলমাত্র আপনার সংস্থা থেকে প্রশাসকগণের দ্বারা অ্যাক্সেস করা যায় তবে আপনার জন্য এসএসএল অনুমোদন হতে পারে। এটি নিশ্চিত করবে যে তাদের ব্রাউজারে অনুমোদিত শংসাপত্র ইনস্টল না করা হলেই কেউ সার্ভারের সাথে সংযোগ স্থাপন করতে পারে না। গত সপ্তাহে আমি সার্ভার সেটআপ করার জন্য একটি নিবন্ধ লিখেছিলাম: আর্টিকেল

এটি এমন একটি সুরক্ষিত সেটআপ যা আপনি দেখতে পাবেন যে কোনও ব্যবহারকারীর নাম / পাসওয়ার্ড জড়িত নেই সুতরাং আপনার ব্যবহারকারীর মধ্যে কেউ কী ফাইলগুলি সম্ভাব্য হ্যাকারের হাতে না দিলে কেউ অ্যাক্সেস পেতে পারে না।

Comments

সুন্দর নিবন্ধ। তবে ব্যক্তিগত অঞ্চলটি ব্যবহারকারীদের জন্য।

— tschiela

ধন্যবাদ - ঠিক আছে, তাহলে আপনার অন্য সমাধানের দিকে যাওয়া উচিত, শংসাপত্র বিতরণ করা ব্যথা হতে পারে।

— এক্সেক্সা