Przerzucam kod z aplikacji wbudowanej w niestandardowy niestandardowy framework PHP do Ruby on Rails (wersja 3). W wersji PHP wszystkie kontrolery są naprawdę grube, z cienkimi modelami, z którymi zawsze się nie zgadzałem, więc cieszę się z tego, jak Rails dokonuje walidacji na poziomie modelu, co prawdopodobnie stanowi 90% tego, co dzieje się w tych kontrolerach tłuszczu. obecnie.Rails 3 Identyfikacja ActiveRecord na podstawie uprawnień użytkownika
Jednym z problemów, przed którymi stoję, i nie wiem, jak rozwiązać, jest jednak to, że różne zasady sprawdzania poprawności zależą od tego, kto dokonuje zmiany modelu. Na przykład administrator lub oryginalny twórca rekordu powinien móc np. Oznaczyć rekord jako usunięty (usuwanie miękkie), podczas gdy wszyscy inni nie powinni.
class Something < ActiveRecord::Base
...
validates :deleted, :owned_by_active_user => true
...
end
class OwnedByActiveUserValidator < ActiveModel::EachValidator
validate_each(record, attr_name, attr_value)
# Bad idea to have the model know about things such as sessions?
unless active_user.admin? || active_user.own?(record)
record.errors.add :base, "You do not have permission to delete this record"
end
end
end
Ponieważ sam model (w teorii) nieświadomy użytkownik, który sprawia, że zmiany, co jest „Szyny drogę” do zrobienia tego typu rzeczy? Czy powinienem ustawić aktywnego użytkownika jako wirtualny atrybut w rekordzie (w rzeczywistości nie zapisany w DB), czy powinienem po prostu wykonać te kontrole w kontrolerze? Muszę przyznać, że posiadanie uprawnień do sprawdzania modelu na aktywnym użytkowniku wydaje się dziwne i zwiększa złożoność, jeśli chodzi o testowanie modelu.
Jednym z powodów, dla których chciałbym zachować jak najwięcej z tego modelu, jest to, że chcę zapewnić zarówno interfejs API (dostępny przez OAuth), jak i stronę internetową, bez duplikowania zbyt wielu kodów, takich jak te rodzaje kontroli uprawnień.
Dzięki, muszę się z tobą zgodzić. Moje modele powinny działać tak, jak im się mówi (pod warunkiem, że pozwala na to logika biznesowa). Moi kontrolerzy powinni zdecydować, kto im mówi. Po prostu upewnię się, że usunę te krwawe szczegóły najlepiej jak potrafię. – d11wtq
Dogma ... Wiem, jak to się robi, ale wydaje mi się, że umieszczenie kontroli dostępu bezpośrednio w modelach to eleganckie rozwiązanie, jeśli uważasz, że modele są twoją warstwą danych API/reguł biznesowych. Pozwala to również uniknąć powtarzania tych samych informacji w wielu kontrolerach, które dotykają tego samego modelu.Używanie sprawdzania poprawności również wydaje się bardzo wygodne - może generować błędy typu "przepraszam, nie masz uprawnień do edycji tego pola". Chociaż to pole nie powinno być pokazywane w pierwszej kolejności. Chciałbym mieć rozwiązanie, które umożliwiłoby introspekcję dla twórców formularzy. – odigity
Można tworzyć klasy formularza (nie oparte na bazach danych), które implementują sprawdzanie poprawności i metody wymagane przez kreator formularzy. – yfeldblum