Come Costruire un’applicazione Ruby on Rails

Introduzione

Rails è un framework per applicazioni web scritto in Ruby. Adotta un approccio opinionato allo sviluppo delle applicazioni, presupponendo che le convenzioni stabilite siano le migliori per i programmatori quando c’è un obiettivo comune. Rails offre quindi convenzioni per la gestione della routing, dei dati Storici, della gestione degli asset e altro, al fine di fornire la funzionalità di base di cui la maggior parte delle applicazioni web ha bisogno.

Rails segue il modello architetturale modello-vista-controllore (MVC), che separa la logica dell’applicazione, situata nei modelli, dalla routing e dalla presentazione delle informazioni dell’applicazione. Questa struttura organizzativa — insieme ad altre convenzioni che consentono ai sviluppatori di estrarre il codice in helpers e parti — garantisce che il codice dell’applicazione non sia ripetuto inutilmente.

In questo tutorial, creerai un’applicazione Rails che permetterà agli utenti di pubblicare informazioni su squali e il loro comportamento. Sarà un buon punto di partenza per lo sviluppo di applicazioni future.

Prerequisiti

Per seguire questo tutorial, avrai bisogno di:

  • Una macchina locale o un server di sviluppo che esegue Ubuntu 18.04. La tua macchina di sviluppo dovrebbe avere un utente non root con privilegi amministrativi e un firewall configurato con ufw. Per istruzioni su come impostare questo sistema, consulta il nostro tutorial Configurazione Iniziale del Server su Ubuntu 18.04.
  • Node.js e npm installati sulla tua macchina locale o sul server di sviluppo. Questo tutorial utilizza Node.js versione 10.16.3 e npm versione 6.9.0. Per indicazioni sull’installazione di Node.js e npm su Ubuntu 18.04, segui le istruzioni nella sezione “Installazione Utilizzando un PPA” di Come Installare Node.js su Ubuntu 18.04.
  • Ruby, rbenv, e Rails installati sul tuo computer locale o server di sviluppo, seguendo i passaggi da 1 a 4 in Come installare Ruby on Rails con rbenv su Ubuntu 18.04. Questa guida utilizza Ruby 2.5.1, rbenv 1.1.2, e Rails 5.2.0.

Passo 1 — Installazione di SQLite3

Prima di creare la nostra applicazione Rails shark, dobbiamo assicurarci di avere un database per memorizzare i dati degli utenti. Rails è configurato per utilizzare SQLite di default, e questo è spesso una buona scelta in fase di sviluppo. Poiché i dati della nostra applicazione non richiedono un alto livello di estendibilità programmatica, SQLite soddisferà le nostre esigenze.

Prima, aggiorna il tuo indice dei pacchetti:

  1. sudo apt update

Successivamente, installa i pacchetti sqlite3 e libsqlite3-dev:

sudo apt install sqlite3 libsqlite3-dev

Questo installerà sia SQLite che i suoi file di sviluppo richiesti.

Controlla la tua versione per confermare che l’installazione sia avvenuta con successo:

  1. sqlite3 --version
Output
3.22.0 2018-01-22 18:45:57 0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2alt1

Con SQLite installato, sei pronto per iniziare a sviluppare la tua applicazione.

Passo 2 — Creazione di un Nuovo Progetto Rails

Con il nostro database installato, possiamo creare un nuovo progetto Rails e dare un’occhiata ad alcuni del codice boilerplate predefinito che Rails ci fornisce con il comando rails new.

Crea un progetto chiamato sharkapp con il seguente comando:

  1. rails new sharkapp

Vedrai una buona quantità di output che ti dice cosa Rails sta creando per il tuo nuovo progetto. L’output qui sotto evidenzia alcuni file, directory e comandi significativi:

Output
create . . . create Gemfile . . . create app . . . create app/controllers/application_controller.rb . . . create app/models/application_record.rb . . . create app/views/layouts/application.html.erb . . . create config create config/routes.rb create config/application.rb . . . create config/environments create config/environments/development.rb create config/environments/production.rb create config/environments/test.rb . . . create config/database.yml create db create db/seeds.rb . . . run bundle install . . . Bundle complete! 18 Gemfile dependencies, 78 gems now installed. Use `bundle info [gemname]` to see where a bundled gem is installed. . . . * bin/rake: Spring inserted * bin/rails: Spring inserted

L’output evidenziato qui ti dice che Rails ha creato quanto segue:

  • Gemfile: Questo file elenca le dipendenze dei gem per la tua applicazione. Un gem è un pacchetto software Ruby, e un Gemfile ti permette di gestire le necessità software del tuo progetto.
  • app: La directory app è dove risiede il codice principale della tua applicazione. Questo include i modelli, i controller, le viste, gli asset, gli helper e i mailer che costituiscono l’applicazione stessa. Rails ti fornisce del codice boilerplate a livello di applicazione per il modello MCV per iniziare nei file come app/models/application_record.rb, app/controllers/application_controller.rb, e app/views/layouts/application.html.erb.
  • Il direttorio config contiene le impostazioni di configurazione dell’applicazione:
    • Il file config/routes.rb è dove vive la dichiarazione delle rotte dell’applicazione.
    • Il file config/application.rb contiene le impostazioni generali per i componenti dell’applicazione.
  • config/environments: Questo direttorio è dove vivono le impostazioni di configurazione per le ambientazioni. Rails include tre ambientazioni predefinite di default: development, production, e test.
  • config/database.yml: I dati di configurazione del database sono nell’file che è suddiviso in quattro sezioni: default, development, production, e test. Grazie al gemma che è arrivato con il comando rails new, che ha incluso il gemma sqlite3, il file config/database.yml ha già il parametro adapter impostato su sqlite3, specificando che usaremo un database SQLite con questa applicazione.
  • db: questa cartella include una directory per le migrazioni del database chiamata migrate, insieme ai file schema.rb e seeds.rb. schema.db contiene informazioni sulla vostra base dati, mentre seeds.rb è dove puoi inserire i dati di default per il database.

Infine, Rails esegue il comando bundle install per installare le dipendenze elencate nel vostro Gemfile.

Una volta che tutto è impostato, naviga fino alla directory sharkapp:

  1. cd sharkapp

Ora puoi avviare il server Rails per assicurarti che il tuo applicativo funziona, usando il comando rails server. Se stai lavorando sulla tua macchina locale, digitare:

  1. rails server

Rails si associa a localhost per default, quindi puoi ora accedere al tuo applicativo navigando il browser a locahost:3000, dove vedrai l’immagine seguente:

Se stai lavorando su un server di sviluppo, prima assicurarti che le connessioni siano consentite sulla porta 3000:

  1. sudo ufw allow 3000

Poi avvia il server utilizzando il flag --binding, per associare la tua IP del server:

  1. rails server --binding=your_server_ip

Navigare a http://your_server_ip:3000 nel tuo browser, dove vedrai il messaggio di benvenuto di Rails.

Una volta fatto un giro, puoi fermare il server con CTRL+C.

Con la tua applicazione creata e in posizione, sei pronto a iniziare a costruire partendo dalla base di Rails per creare un’applicazione unica.

Step 3 — Scaffolding the Application

Per creare la nostra applicazione informativa sugli squali, dovremo creare un modello per gestire i dati dell’applicazione, viste per consentire all’utente di interagire con quei dati, e un controller per gestire la comunicazione tra il modello e le viste. Per costruire queste cose useranno il comando rails generate scaffold, che ci darà un modello, una migrazione del database per modificare lo schema del database, un controller, una serie completa di viste per gestire le operazioni Create, Read, Update, and Delete (CRUD) per l’applicazione, e template per parti, helper e test.

Poiché il comando generate scaffold ci fa molto lavoro, ci prenderemo un’occhiata più da vicino ai risorse che crea per capire il lavoro che Rails sta facendo dietro le quinte.

Il nostro comando generate scaffold includerà il nome del nostro modello e i campi che desideriamo nella nostra tabella del database. Rails utilizza Active Record per gestire le relazioni tra i dati dell’applicazione, costruiti come oggetti con modelli, e il database dell’applicazione. Ognuno dei nostri modelli è una classe Ruby, mentre eredita anche dalla classe ActiveRecord::Base. Ciò significa che possiamo lavorare con la nostra classe modello allo stesso modo in cui lavoreremmo con una classe Ruby, pur importando metodi da Active Record. Active Record garantirà quindi che ogni classe sia mappata su una tabella nel nostro database e ogni istanza di quella classe su una riga in quella tabella.

Digita il seguente comando per generare un modello Shark, un controller e le viste associate:

  1. rails generate scaffold Shark name:string facts:text

Con name:string e facts:text stiamo fornendo a Rails informazioni sui campi che desideriamo nella nostra tabella del database e sul tipo di dati che dovrebbero accettare. Entrambi ci daranno spazio per inserire ciò che desideriamo, anche se text permetterà più caratteri per i fatti sui squali.

Quando digiti questo comando, vedrai di nuovo un lungo elenco di output che spiega tutto ciò che Rails sta generando per te. L’output seguente evidenzia alcune delle cose più significative per la nostra configurazione:

Output
invoke active_record create db/migrate/20190804181822_create_sharks.rb create app/models/shark.rb . . . invoke resource_route route resources :sharks invoke scaffold_controller create app/controllers/sharks_controller.rb invoke erb create app/views/sharks create app/views/sharks/index.html.erb create app/views/sharks/edit.html.erb create app/views/sharks/show.html.erb create app/views/sharks/new.html.erb create app/views/sharks/_form.html.erb . . .

Rails ha creato il modello in app/models/shark.rb e una migrazione del database per accompagnarlo: db/migrate/20190804181822_create_sharks.rb. Il timestamp sul tuo file di migrazione sarà diverso da quello che vedi qui.

Ha anche creato un controller, app/controllers/sharks_controller.rb, così come le viste associate alle operazioni CRUD della nostra applicazione, raccolte sotto app/views/sharks. Tra queste viste c’è una partial, _form.html.erb, che contiene il codice utilizzato in tutte le viste.

Infine, Rails ha aggiunto una nuova risorsa, resources :sharks, a config/routes.rb. Questo permette al router di Rails di far corrispondere le richieste HTTP in entrata con il controller sharks e le sue viste associate.

Anche se Rails ha svolto gran parte del lavoro di sviluppo del nostro codice applicativo, vale la pena dare un’occhiata ad alcuni file per capire cosa sta succedendo.

Prima di tutto, diamo un’occhiata al file del controller con il seguente comando:

  1. cat app/controllers/sharks_controller.rb
Output
class SharksController < ApplicationController before_action :set_shark, only: [:show, :edit, :update, :destroy] # GET /sharks # GET /sharks.json def index @sharks = Shark.all end # GET /sharks/1 # GET /sharks/1.json def show end # GET /sharks/new def new @shark = Shark.new end # GET /sharks/1/edit def edit end # POST /sharks # POST /sharks.json def create @shark = Shark.new(shark_params) respond_to do |format| if @shark.save format.html { redirect_to @shark, notice: 'Shark was successfully created.' } format.json { render :show, status: :created, location: @shark } else format.html { render :new } format.json { render json: @shark.errors, status: :unprocessable_entity } end end end # PATCH/PUT /sharks/1 # PATCH/PUT /sharks/1.json def update respond_to do |format| if @shark.update(shark_params) format.html { redirect_to @shark, notice: 'Shark was successfully updated.' } format.json { render :show, status: :ok, location: @shark } else format.html { render :edit } format.json { render json: @shark.errors, status: :unprocessable_entity } end end end # DELETE /sharks/1 # DELETE /sharks/1.json def destroy @shark.destroy respond_to do |format| format.html { redirect_to sharks_url, notice: 'Shark was successfully destroyed.' } format.json { head :no_content } end end private # Utilizza callback per condividere configurazioni comuni o vincoli tra azioni. def set_shark @shark = Shark.find(params[:id]) end # Non fidarti mai dei parametri provenienti dalla terribile internet, permetti solo la whitelist. def shark_params params.require(:shark).permit(:name, :facts) end end

Il controller è responsabile della gestione di come le informazioni vengono recuperate e passate al suo modello associato, e di come vengono associate a particolari viste. Come puoi vedere, il nostro controller sharks include una serie di metodi che mappano grossolanamente alle operazioni CRUD standard. Tuttavia, ci sono più metodi delle funzioni CRUD, per consentire l’efficienza in caso di errori.

Ad esempio, considera il metodo create:

~/sharkapp/app/controllers/sharks_controller.rb
. . .
  def create
    @shark = Shark.new(shark_params)

    respond_to do |format|
      if @shark.save
        format.html { redirect_to @shark, notice: 'Shark was successfully created.' }
        format.json { render :show, status: :created, location: @shark }
      else
        format.html { render :new }
        format.json { render json: @shark.errors, status: :unprocessable_entity }
      end
    end
  end
. . . 

Se una nuova istanza della classe Shark viene salvata con successo, redirect_to genererà una nuova richiesta che verrà poi indirizzata al controller. Questa sarà una richiesta GET e sarà gestita dal metodo show, che mostrerà all’utente lo squalo che hanno appena aggiunto.

Se c’è un fallimento, allora Rails renderà nuovamente il template app/views/sharks/new.html.erb piuttosto che fare un’altra richiesta al router, dando agli utenti un’altra possibilità di inviare i loro dati.

Oltre al controller degli squali, Rails ci ha fornito un modello per una vista index, che corrisponde al metodo index nel nostro controller. Useremo questa come vista principale per la nostra applicazione, quindi vale la pena dare un’occhiata.

Digita quanto segue per visualizzare il file:

  1. cat app/views/sharks/index.html.erb
Output
<p id="notice"><%= notice %></p> <h1>Sharks</h1> <table> <thead> <tr> <th>Name</th> <th>Facts</th> <th colspan="3"></th> </tr> </thead> <tbody> <% @sharks.each do |shark| %> <tr> <td><%= shark.name %></td> <td><%= shark.facts %></td> <td><%= link_to 'Show', shark %></td> <td><%= link_to 'Edit', edit_shark_path(shark) %></td> <td><%= link_to 'Destroy', shark, method: :delete, data: { confirm: 'Are you sure?' } %></td> </tr> <% end %> </tbody> </table> <br> <%= link_to 'New Shark', new_shark_path %>

La vista index itera attraverso le istanze della nostra classe Shark, che sono state mappate alla tabella sharks nel nostro database. Utilizzando ERB templating, la vista genera ogni campo dalla tabella associato a un’istanza individuale di squalo: name e facts.

La vista poi utilizza l’helper link_to per creare un collegamento ipertestuale, con la stringa fornita come testo del link e il percorso fornito come destinazione. I percorsi stessi sono resi possibili attraverso gli helper che ci sono diventati disponibili quando abbiamo definito la rotta resourceful sharks con il comando rails generate scaffold.

Oltre a guardare la nostra vista index, possiamo anche dare un’occhiata alla vista new per vedere come Rails utilizza i partial nelle viste. Digita quanto segue per visualizzare il template app/views/sharks/new.html.erb:

  1. cat app/views/sharks/new.html.erb
Output
<h1>New Shark</h1> <%= render 'form', shark: @shark %> <%= link_to 'Back', sharks_path %>

Anche se questo template potrebbe sembrare privo di campi di input per una nuova voce di squalo, il riferimento a render 'form' ci dice che il template sta includendo il partial _form.html.erb, che estrae il codice ripetuto attraverso le viste.

Esaminando quel file ci darà una visione completa di come viene creato un nuovo’istanza di squalo:

  1. cat app/views/sharks/_form.html.erb
Output
<%= form_with(model: shark, local: true) do |form| %> <% if shark.errors.any? %> <div id="error_explanation"> <h2><%= pluralize(shark.errors.count, "error") %> prohibited this shark from being saved:</h2> <ul> <% shark.errors.full_messages.each do |message| %> <li><%= message %></li> <% end %> </ul> </div> <% end %> <div class="field"> <%= form.label :name %> <%= form.text_field :name %> </div> <div class="field"> <%= form.label :facts %> <%= form.text_area :facts %> </div> <div class="actions"> <%= form.submit %> </div> <% end %>

Questo template utilizza il form_with helper per form. Gli helper per form sono progettati per facilitare la creazione di nuovi oggetti a partire dall’input dell’utente utilizzando i campi e l’ambito di modelli specifici. Qui, form_with prende model: shark come argomento, e il nuovo oggetto builder di form che crea ha campi di input che corrispondono ai campi nella tabella sharks. Pertanto, gli utenti hanno campi di form per inserire sia il name che i facts dello squalo.

Inviando questo form si creerà una risposta JSON con i dati dell’utente che il resto della tua applicazione può accedere tramite il metodo params, che crea un oggetto ActionController::Parameters con quei dati.

Ora che sai cosa ha prodotto rails generate scaffold per te, puoi procedere a impostare la vista principale per la tua applicazione.

Passo 4 — Creazione della Vista Principale dell’Applicazione e Test della Funzionalità

Idealmente, desideri che la pagina di destinazione della tua applicazione corrisponda alla radice dell’applicazione, in modo che gli utenti possano immediatamente comprendere lo scopo dell’applicazione.

Esistono diversi modi per gestire questo: ad esempio, potresti creare un controller Welcome e una vista associata index, che fornirebbe agli utenti una pagina di destinazione generica che potrebbe anche collegarsi a diverse parti dell’applicazione. Tuttavia, nel nostro caso, far atterrare gli utenti sulla nostra vista index dei squali sarà sufficiente per ora per introdurre lo scopo dell’applicazione.

Per configurare questo, dovrai modificare le impostazioni di routing in config/routes.rb per specificare la radice dell’applicazione.

Apri config/routes.rb per la modifica, utilizzando nano o il tuo editor preferito:

  1. nano config/routes.rb

Il file avrà un aspetto simile a questo:

~/sharkapp/config/routes.rb
Rails.application.routes.draw do
  resources :sharks
  # Per dettagli sul DSL disponibile all'interno di questo file, vedi http://guides.rubyonrails.org/routing.html
end

Senza impostare qualcosa di più specifico, la vista predefinita a http://localhost:3000 o http://your_server_ip:3000 sarà la pagina di benvenuto predefinita di Rails.

Per mappare la vista radice dell’applicazione al index della controller delle squali, devi aggiungere la seguente riga al file:

~/sharkapp/config/routes.rb
Rails.application.routes.draw do
  resources :sharks

  root 'sharks#index' 
  Per informazioni sul DSL disponibile all'interno di questo file, consultate http://guides.rubyonrails.org/routing.html
end

Ora, quando i utenti navigano alla root della tua applicazione, verranno mostrati un elenco completo di squali e avverranno la possibilità di creare una nuova entrata, guardare le entrate esistenti e modificarle o eliminarle.

Salva il file e uscite dall’editor quando hai finito di modificarlo. Se hai usato nano per modificare il file, puoi fare così: premendo CTRL+X, Y, poi ENTER.

Puoi ora eseguire le migrazioni con il comando seguente:

  1. rails db:migrate

Vedrete l’output che conferma la migrazione.

Riparte il tuo server Rails una volta ancora. Se lavori localmente, scrivi:

  1. rails s

Se lavori su un server di sviluppo, scrivi:

  1. rails s --binding=your_server_ip

Navighe all’indirizzo localhost:3000 se lavori localmente, oppure all’indirizzo http://tuo_server_ip:3000 se lavori su un server di sviluppo.

La pagina di arrivo dell’applicazione sarà come questa:

Per creare un nuovo squalo clicca sul link Nuovo Squalo all’interno della pagina, che ti porterà alla route sharks/new:

Inserisci “Great White” nel campo Nome e “Scary” nel campo Fatti:

Clicca sul pulsante Crea per creare lo squalo.

Questo ti guiderà al percorso show, che, grazie al filtro before_action, è impostato con il metodo set_shark, che raccoglie l’ID del squalo che hai appena creato:

~/sharkapp/app/controllers/sharks_controller.rb
class SharksController < ApplicationController
  before_action :set_shark, only: [:show, :edit, :update, :destroy]

  . . . 

  def show
  end

  . . . 

  private
    # Usa callback per condividere la configurazione o le restrizioni comuni tra azioni.
    def set_shark
      @shark = Shark.find(params[:id])
    end
  . . .

Puoi testare ora la funzione di edizione cliccando Edita sulla tua entrata di squalo. Ci avvicinerai alla edit della tua entrata di squalo:

Modifica le fatti sulle Great White in modo che si leggano “Grandi” invece di “Scari”. Clicca Aggiorna Squalo. Questo ti farà tornare al percorso show:

Finally, clicking Torna will take you to your updated index view:

Ora che hai testato la funzionalità base dell’applicazione, puoi aggiungere alcune verifiche valide e controlli di sicurezza per rendere tutto più sicuro.

Il tuo applicazione squalo può accettare input dall’utente, ma immagina un caso in cui un utente tenta di creare un squalo senza aggiungerci fatti o tenta di inserire una voce per un squalo che è già nel database. Puoi creare meccanismi per controllare i dati di input prima che arrivino al database aggiungendo validazioni ai tuoi modelli. Poiché la logica dell’applicazione è nelle sue model, valorizzare i dati qui è più sensibile rispetto ad altri punti dell’applicazione.

Nota che non tratteremo la scrittura di test di validazione in questo tutorial, ma puoi scoprire di più sui test consultando la documentazione di Rails.

Se non hai ancora arrestato il server, fallo adesso digitando CTRL+C.

Apri il file del modello shark.rb:

  1. nano app/models/shark.rb

Attualmente, il file ci dice che la classe Shark eredita da ApplicationRecord, che a sua volta eredita da ActiveRecord::Base:

~/sharkapp/app/models/shark.rb
class Shark < ApplicationRecord
end

Aggiungiamo prima alcune validazioni al campo name per confermare che il campo sia compilato e che la voce sia unica, evitando così voci duplicate:

~/sharkapp/app/models/shark.rb
class Shark < ApplicationRecord
  validates :name, presence: true, uniqueness: true
end

Successivamente, aggiungi una validazione per il campo facts per assicurarti che anche questo sia compilato:

~/sharkapp/app/models/shark.rb
class Shark < ApplicationRecord
  validates :name, presence: true, uniqueness: true
  validates :facts, presence: true
end

Qui siamo meno preoccupati della unicità dei fatti, purché siano associati a voci di squali uniche.

Salva e chiudi il file quando hai finito.

Riavvia il server una volta di nuovo con rails s o rails s --binding=your_server_ip, a seconda che tu stia lavorando localmente o con un server di sviluppo.

Naviga alla radice della tua applicazione all’indirizzo http://localhost:3000 o http://your_server_ip:3000.

Clicca su Nuovo Squalo. Nel modulo, aggiungi “Grande Bianco” al campo Nome e “Grandi Denti” al campo Fatti, poi clicca su Crea Squalo. Dovresti vedere il seguente avviso:

Ora, vediamo se possiamo controllare l’altra convalida. Clicca Indietro per tornare alla homepage, e poi Nuovo Squalo di nuovo. Nel nuovo modulo, inserisci “Squalo Tigre” nel campo Nome, e lascia Fatti vuoto. Cliccando su Crea Squalo si attiverà il seguente avviso:

Con queste modifiche, la tua applicazione ha alcune convalide in atto per garantire la coerenza dei dati salvati nel database. Ora puoi dedicarti agli utenti della tua applicazione e definire chi può modificare i dati dell’applicazione.

Passo 6 — Aggiunta dell’Autenticazione

Con le convalide in atto, abbiamo alcune garanzie sui dati che vengono salvati nel database. Ma per quanto riguarda gli utenti? Se non vogliamo che qualsiasi utente possa aggiungere al database, allora dovremmo aggiungere alcune misure di autenticazione per assicurarci che solo gli utenti autorizzati possano aggiungere squali. Per fare questo, useremo il http_basic_authenticate_with metodo, che ci permetterà di creare una combinazione di nome utente e password per autenticare gli utenti.

Esistono diversi metodi per autenticare gli utenti con Rails, tra cui l’utilizzo delle gemme bcrypt o devise. Per ora, tuttavia, aggiungeremo un metodo al nostro Application Controller che si applica alle azioni in tutta la nostra applicazione. Questo sarà utile se aggiungiamo più controller all’applicazione in futuro.

Arresta nuovamente il tuo server con CTRL+C.

Apri il file che definisce il tuo ApplicationController:

  1. nano app/controllers/application_controller.rb

All’interno, troverai la definizione della classe ApplicationController, da cui ereditano gli altri controller della tua applicazione:

~/sharkapp/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
end

Per autenticare gli utenti, utilizzeremo un nome utente e una password hardcoded con il metodo http_basic_authenticate_with. Aggiungi il seguente codice al file:

~/sharkapp/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  http_basic_authenticate_with name: 'sammy', password: 'shark', except: [:index, :show]
end

Oltre a fornire il nome utente e la password qui, abbiamo anche limitato l’autenticazione specificando le rotte dove non dovrebbe essere richiesta: index e show. Un altro modo per ottenere questo risultato sarebbe stato scrivere only: [:create, :update, :destroy]. In questo modo, tutti gli utenti potranno guardare tutti gli squali e leggere fatti su particolari squali. Quando si tratta di modificare il contenuto del sito, tuttavia, gli utenti dovranno dimostrare di avere accesso.

In una configurazione più robusta, non vorresti codificare valori in questo modo, ma a scopo dimostrativo, questo ti permetterà di vedere come puoi includere l’autenticazione per le route della tua applicazione. Ti consente inoltre di vedere come Rails memorizza i dati di sessione per impostazione predefinita nei cookie: una volta autenticato in un’azione specificata, non sarai più richiesto di autenticarti nella stessa sessione.

Salva e chiudi app/controllers/application_controller.rb quando hai finito di modificare. Ora puoi testare l’autenticazione in azione.

Avvia il server con rails s o rails s --binding=your_server_ip e naviga verso la tua applicazione all’indirizzo http://localhost:3000 o http://your_server_ip:3000.

Nella pagina di destinazione, clicca sul pulsante Nuovo Squalo. Questo attiverà la seguente finestra di autenticazione:

Se inserisci la combinazione nome utente e password che hai aggiunto in app/controllers/application_controller.rb, sarai in grado di creare in modo sicuro un nuovo squalo.

Ora hai un’applicazione di squali funzionante, completa di convalide dei dati e uno schema di autenticazione di base.

Conclusione

L’applicazione Rails che hai creato in questo tutorial è un punto di partenza che puoi utilizzare per ulteriori sviluppi. Se sei interessato a esplorare l’ecosistema Rails, la documentazione del progetto è un ottimo punto di partenza.

Puoi anche approfondire l’aggiunta di risorse nidificate al tuo progetto leggendo Come Creare Risorse Nidificate per un’Applicazione Ruby on Rails, che ti mostrerà come sviluppare i modelli e le rotte della tua applicazione.

Inoltre, potresti voler esplorare come configurare un frontend più robusto per il tuo progetto con un framework come React. Come Configurare un Progetto Ruby on Rails con un Frontend React offre indicazioni su come fare questo.

Se desideri esplorare diverse opzioni di database, puoi anche consultare Come utilizzare PostgreSQL con la tua applicazione Ruby on Rails su Ubuntu 18.04, che illustra come lavorare con PostgreSQL invece di SQLite. Puoi anche consultare la nostra libreria di tutorial su PostgreSQL per saperne di più sull’uso di questo database.

Source:
https://www.digitalocean.com/community/tutorials/how-to-build-a-ruby-on-rails-application