Area amministrazione

ciao a tutti.
avendo le idee confuse vengo subito al sodo e vi descrivo il mio
problema:

sto facendo un blog per imparare rails.

ho generato con lo scaffolding 2 controller e model:
post controller e model
category controller e model

adesso ho intenzione di creare un solo controller ‘blog’ che mi permetta
di vedere sia i post che le category da un layout ‘blog’ (questo lo so
fare, lo descrivo solo per far capire meglio il mio problema).

detto questo

  • voglio un area di login ( /login ) in cui l’amministratore si logga
    per poter gestire i post e le category, quindi non ho bisogno di
    registrare gli utenti, devo gestire solo l’amministratore.

  • vorrei che le azioni index edit new destroy di ogni controller fossero
    ammesse solo all’utente loggato

  • vorrei (una volta che l’utente si è loggato) far comparire un div nel
    layout con i link per le action index dei due controller

ho visto che ci sono diversi plugin, authlogic, devise,
restful_authentication ma quale si adatta meglio alle mie esigenze?
quale è il più semplice da installare e gestire?

voi come vi comportereste in questo caso?

grazie a tutti!

2010/12/10 Dino D. [email protected]:

ho visto che ci sono diversi plugin, authlogic, devise,
restful_authentication ma quale si adatta meglio alle mie esigenze?
quale il pi semplice da installare e gestire?

la mia soluzione di default per app
single-user-che-sono-io-e-sono-sviluppatore :

before_filter :authenticate

def authenticate
# o digest
authenticate_or_request_with_http_basic do |id, password|
id == “miouser” && password == “miapass”
end
end

con user & pass cablati. Pi semplice di cos’ non c’, ma ovviamente
la flessibilit quel che :slight_smile:


blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com
work: http://cascaad.com

gabriele renzi wrote in post #967813:

2010/12/10 Dino D. [email protected]:

ho visto che ci sono diversi plugin, authlogic, devise,
restful_authentication ma quale si adatta meglio alle mie esigenze?
quale il pi semplice da installare e gestire?

la mia soluzione di default per app
single-user-che-sono-io-e-sono-sviluppatore :

before_filter :authenticate

def authenticate
# o digest
authenticate_or_request_with_http_basic do |id, password|
id == “miouser” && password == “miapass”
end
end

con user & pass cablati. Pi semplice di cos’ non c’, ma ovviamente
la flessibilit quel che :slight_smile:


blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com
work: http://cascaad.com

grazie della risposta ma ho risolto.
soluzione: basta seguire gli episodi 19 - 20 - 21 su railcasts.com

comunque grazie!!
alla prossima :slight_smile:

Scusate se mi intrometto nella discussione, quella della gestione dei
layout per area pubblica e di autenticazione è un problema che mi si sta
ponendo attualmente: in pratica io vorrei che esistessero di fatto 2
layout completamente differenti, uno per la parte pubblica e l’altro per
la parte privata.

Come vi orientate voi per questa possibilità? Io avevo pensato di creare
due sottocartelle nella sezione “views/layouts” contenenti i due
layouts, richiamando l’uno o l’altro a seconda della classe richiesta (e
quindi della sezione visitata).

Ovviamente parlo da neofita, quindi consigli sono ben accetti :slight_smile:

Il 10/12/2010 15:01, Dino D. ha scritto:

  • voglio un area di login ( /login ) in cui l’amministratore si logga
    per poter gestire i post e le category, quindi non ho bisogno di
    registrare gli utenti, devo gestire solo l’amministratore.
    io partire da questo articolo:
    http://asciicasts.com/episodes/160-authlogic

ho sempre usato authlogic per queste cose. se poi hai bisogno di un
sistema pi
avanzato (registrazioni, conferme, reminders, etc…), allora vai con
devise :wink:

  • vorrei che le azioni index edit new destroy di ogni controller fossero
    ammesse solo all’utente loggato
    nell’articolo che ti ho linkato spiega come ottenere l’utente loggato
    (current_user), per controllare che ci sia un utente loggato, basta
    aggiungere
    questo metodo in ApplicationController:


def authorize
@user_session ||= UserSession.find
unless (@user_session && @user_session.record)
flash[:error] = “Devi essere autenticato.”
redirect_to login_path
end
end

infine, devi inserire questa macro:

before_filter :authorize

decidi tu dove metterla:

  • singolarmente su ciascun controller

  • in ApplicationController in modo da applicarlo per default a tutti i
    controllers della tua applicazione, andando poi a scremare eventuali
    azioni/controllers che ritieni pubblici, usando la direttiva:

    skip_before_filter :authorize

personalmente uso sempre il secondo metodo, in questo modo posso solo
rischiare
di negare l’accesso al pubblico, ma non rischio di offrire una pagina di
amministrazione a chi non autorizzato ( un ragionamento che volgarmente
chiamo “blocca tutto tranne…”) :stuck_out_tongue:

  • vorrei (una volta che l’utente si loggato) far comparire un div nel
    layout con i link per le action index dei due controller
    l’articolo sopra spiega anche questo :wink:

ho visto che ci sono diversi plugin, authlogic, devise,
restful_authentication ma quale si adatta meglio alle mie esigenze?
quale il pi semplice da installare e gestire?
ho provato solo authlogic e devise, nel tuo caso sicuramente opterei per
authlogic, oppure la soluzione che ti ha indicato Gabriele Renzi :wink:

voi come vi comportereste in questo caso?
se solo un blog con il quale fare esperimenti ed evitare di duplicare
troppo
codice, potresti creare un BlogController che si occupa di offrire:
* un layout per la grafica da mostrare al pubblico
* la index dei posts (es. esempio.com)
* la show di un singolo Post (es. esempio.com/id-o-permalink-post)
* i posts di una singola Category (es.
esempio.com/category/id-o-permalink-categoria)

i controllers e le views generati con lo scaffold, li userai per
l’amministrazione, lasciando il layout di default, magari aggiungendo
una barra
links per spostarti tra i Posts e le Categories, o fare logout.

pi semplice e veloce di cos, non mi viene in mente altro :stuck_out_tongue:

ciao,
A.


http://twitter.com/apeacox

ciao Marco,

ti basta creare un nuovo file di layout in views/layouts, poi puoi
decidere
quale usare specificando il layout di default in ApplicationController
e/o
mettendolo nei controller/action che ti interessano.

la scelta dipende anche da come hai impostato la tua app.

ciao,
A.

Il 13/12/2010 12:08, Marco P. ha scritto:

Ovviamente parlo da neofita, quindi consigli sono ben accetti :slight_smile:


http://twitter.com/apeacox

Cari Paolo e Andrea, vi ringrazio per l’aiuto, mi son documentato e
posso cercare di parlare con cognizione di causa maggiore.

Ho capito perfettamente l’uso dei layout a seconda del controller, quel
che voglio capire ora è “come” si organizzano i controller per creare
una sezione riservata ordinata e funzionale.
Cerco di spiegarmi meglio.
Dire “il controller A usa il layout 1 ed il B il 2” è secondo me
riduttivo: alcune pagine, come ad esempio l’elenco di tutti i record e
la visualizzazione di un singolo record, sono condivise tra le due
sezioni.

Immaginiamo un sistema di news:

  • L’utente normale deve poter accedere all’elenco delle news dall’ultimo
    inserimento al primo inserimento.
  • L’utente normale deve poter selezionare e visualizzare una determinata
    news.

L’admin deve poter accedere alle stesse pagine con lo stesso layout
(zona pubblica) o con un un layout diverso dall’utente normale: come
attuare questa divisione?
Bisogna replicare codice?
Si crea un controller chiamato “Admin” generico per la parte riservata e
per le varie sezioni del sito si creano nuovi controller che ereditano
da questo?

Mi scuso ancora per le domande che ai più sembreranno sciocche… Più
che di implementazione ora necessito di “capire” come muovermi con
Rails, per il resto si può ovviare con google ma alcuni concetti
spiegati da professionisti hanno un altro valore.

Grazie a tutti!

Ciao a tutti, magari la parte di guida ufficiale su render e layout
pu fugare tutti i dubbi:

thesp0nge

2010/12/13 Marco P. [email protected]:

Ovviamente parlo da neofita, quindi consigli sono ben accetti :slight_smile:


Posted via http://www.ruby-forum.com/.


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


“… static analysis is fun, again!”

OWASP Orizon project leader, http://github.com/owasp-orizon
OWASP Esapi Ruby project leader,
GitHub - thesp0nge/owasp-esapi-ruby: The Owasp Esapi Ruby is a port for outstanding release quality Owasp Esapi project to the Ruby programming language. The idea is to build a Ruby gem (the standard ruby library archive format) containing the Esapi concepts implemented in Ruby classes so people using Ruby in their Rails application can have security into them.

ciao Marco,

in realt ti avevo gi indicato una strada fattibile per non ripetere
codice:

  • i controller generati con lo scaffold li usi per l’amministratore
  • per l’utente normale crei un controller a parte che si occupa di fare
    la index
    e la show delle news

in questo modo avrai un’area pubblica visibile da tutti, ed una di
amministrazione protetta da password. se poi giocherelli un po’ con le
routes
puoi anche inserire i controllers di amminstrazione sotto una URL con
prefisso
/admin/ :slight_smile:

questa una strada delle tante. hai anche altre possibilit:

  • ripetere il codice dei controller replicando alcune action (index e
    show,
    appunto), ma non ha nessun senso
  • usare qualche plugin/gemma che crea un’area amministrazione in
    automatico
    (typus o rails_admin sono solo due esempi)

secondo me non c’ una best-practice, solo buon senso e ragionamento su
cosa
vuoi/devi fare, scegliendo di volta in volta il metodo che ti permette
di
scrivere meno codice, evitare ripetizioni, e che possibilmente ti
permetta di
aggiornare/modificare/migliorare quello che hai gi fatto. ma questi sono
concetti che prescindono da rails :wink:

ciao,
A.

Il 17/12/2010 22:39, Marco P. ha scritto:

sezioni.
Bisogna replicare codice?


http://twitter.com/apeacox

Grazie mille, sei stato molto gentile e disponibile.
QUel che mi hai suggerito è in effetti quello che avevo già pensato di
creare da solo, ovvero generare degli scaffold per la parte riservata
(ed untilizzare quindi un layout ben definito) e crearne ad hoc per la
parte pubblica, utilizzando dei prefissi per il nome dei controller
(Admin / Public).

Sembra anche a me la strada più semplice da utilizzare e la più
“pulita”.

A buon rendere :wink:

Io di solito creo un namespace admin per i controller
dell’amministrazione, quindi li metto tutti nella cartella admin con
namespace Admin:: e creo un controller di base chiamato
Admin::BaseController. Tutti questi controller ereditano da
Admin::BaseController, nel quale metto tutte le “configurazione” da
condividere in tutte le parti dell’admin, come layout, autenticazione
etc…

  • posts_controller.rb ( controller pubblico )
  • admin
    - base_controller.rb (Admin::BaseController <
    ApplicationController )
    - posts_controller.rb ( Admin::PostsController <
    Admin::BaseController )

2010/12/19 Marco P. [email protected]:

A buon rendere :wink:


Posted via http://www.ruby-forum.com/.


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Andrea F.

anche io seguo questo metodo nella stessa situazione :wink:

ma il problema rimanere DRY, e non sempre facile.

per esempio, mi sono trovato (ehm… mi ci trovo ancora :P) nella
situazione di
dover offrire gli stessi contenuti su due sotto-domini, l’unica
differenza il
colore del layout e poco altro. la soluzione stata molto simile al
discorso
dei namespace che hai postato te, con l’unica differenza che faccio
ereditare i
controller tra loro:

ContentController < ApplicationController

Subdomain::ContentController < ContentController #qui dentro ho potuto
specificare qualche impostazione differente, come il layout ed i filtri
per
l’autenticazione

in questo modo non ho dovuto ripetere nemmeno le action. infine, l’altro
problema era il path delle view: in questo caso, per non ripetere anche
quelle,
ho usato i symlinks:

 app/views/content -> app/views/subdomain/content

un saluto a tutti,
A.

Il 20/12/2010 06:53, Andrea F. ha scritto:

   - base_controller.rb (Admin::BaseController<  ApplicationController )
   - posts_controller.rb ( Admin::PostsController<  Admin::BaseController )
   ...


http://twitter.com/apeacox

2010/12/20 Andrea P. [email protected]:

anche io seguo questo metodo nella stessa situazione :wink:

ma il problema rimanere DRY, e non sempre facile.

se i controller sono front-end e back-end per ma ha senso duplicarli
perch non detto che restino sempre tutte le stesse funzionalit sia
da una parte che dall’altra.

per esempio, mi sono trovato (ehm… mi ci trovo ancora :P) nella situazione di
dover offrire gli stessi contenuti su due sotto-domini, l’unica differenza il
colore del layout e poco altro. la soluzione stata molto simile al discorso

Se sono poche cose che cambiano come layout etc, lascerei un solo
controller che imposta layout e altro a seconda della request e quindi
del dominio.

problema era il path delle view: in questo caso, per non ripetere anche quelle,

dell’amministrazione, quindi li metto tutti nella cartella admin con


http://twitter.com/apeacox


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Andrea F.