R.Reddington

R.Reddington

WFN Üye
Konular
562
Mesajlar
562
Çözüm
0
Ticaret Puanı
0
Üyelik
24 Gün
Konum
Kastamonu
Web Sitesi
Var
Alanı
Sosyal Backlink
1/1
Konu sahibi
İlk paragrafta ana yanıtı, izlenecek yolu ve ulaşılabilecek sonucu doğrudan ver. İşlem gerekiyorsa sonucu değiştiren temel koşulu belirt. Ruby on Rails’te e-posta göndermek için bir ActionMailer sınıfı oluşturulur, ileti şablonu hazırlanır, SMTP bilgileri ortam yapılandırmasına eklenir ve ileti deliver_now veya deliver_later ile gönderilir. Geliştirme ortamında teslimat yerine e-postayı tarayıcıda görüntüleme ya da teslimatı açma-kapama ayarı kullanılabilir; üretimde ise SMTP sunucusunun adresi, portu, kullanıcı bilgisi, parolası ve TLS ayarları doğru yapılandırılmalıdır. Gönderme çağrısının hata vermemesi, iletinin alıcının gelen kutusuna kesin ulaştığını tek başına kanıtlamaz; teslimat sonucu SMTP günlükleri ve sağlayıcının gönderim kayıtlarıyla ayrıca izlenmelidir.

Mailer sınıfını oluşturma​


Örneğin uygulamada yeni kullanıcıya hoş geldin e-postası göndereceğinizi varsayalım. Proje dizininde şu komutu çalıştırın:

Bash: 
bin/rails generate mailer UserMailer welcome

Bu komut bir mailer sınıfı ve ileti görünüm dosyaları oluşturur. Oluşan mailer dosyasında kullanıcıyı bulup iletiye aktarın. Örneğin kullanıcı nesnesini @user değişkenine atayabilirsiniz:

Ruby: 
class UserMailer < ApplicationMailer
  def welcome(user)
    @user = user

    mail(
      to: @user.email,
      subject: "Hoş geldiniz"
    )
  end
end

Buradaki to alıcının adresini, subject ise e-postanın konu satırını belirler. Alıcı adresi kullanıcıdan geliyorsa, gönderimden önce adresin uygulamanızın doğrulama kurallarıyla kontrol edilmesi gerekir. E-posta adresini kullanıcı girdisinden doğrudan ve doğrulamadan kullanmak hatalı veya kötüye kullanılabilir gönderimlere yol açabilir.

E-posta görünümünü hazırlama​


Mailer oluşturulduğunda genellikle HTML ve düz metin görünümleri için dosyalar hazırlanır. HTML görünümünde, mailer içindeki @user değişkenini kullanarak iletiyi yazabilirsiniz:

Kod: 
<h1>Hoş geldiniz, <%= @user.name %></h1>
<p>Hesabınız oluşturuldu.</p>

Aynı ileti için düz metin görünümü de hazırlayın:

Kod: 
Hoş geldiniz, <%= @user.name %>.

Hesabınız oluşturuldu.

Rails, uygun istemciler için HTML ve düz metin parçalarını birlikte sunabilir. Sadece HTML e-posta hazırlamak bazı alıcı istemcilerinde erişilebilirlik ve görüntüleme sorunları oluşturabileceğinden, düz metin karşılığını da yazmak daha güvenlidir.

Gönderim çağrısını yapmak​


Mailer metodu, normal bir Ruby nesnesi gibi çağrılır; ancak e-postayı gerçekten göndermek için teslimat metodu eklenmelidir:

Ruby: 
UserMailer.welcome(user).deliver_now

deliver_now, iletiyi işlem sırasında hemen göndermeyi dener. Bu yöntem basit testlerde veya işlemin e-posta sonucu alınmadan tamamlanmaması gereken sınırlı durumlarda kullanılabilir. Ancak SMTP bağlantısı yavaşsa veya uzak sunucu yanıt vermiyorsa web isteği de bekler.

Uzun sürebilecek gönderimleri arka plana almak için şu biçimi kullanın:

Ruby: 
UserMailer.welcome(user).deliver_later

deliver_later işi uygulamanın etkin kuyruk altyapısına bırakır. Üretimde bunu kullanacaksanız kuyruk işleyicinizin çalıştığını ve başarısız işlerin izlenebildiğini doğrulayın. Kuyruk işleyicisi çalışmıyorsa uygulama gönderim isteğini kuyruğa eklemiş görünse bile e-posta gönderilmez.

Örneğin kullanıcı oluşturma işleminden sonra gönderim yapmak için ilgili servis veya denetleyicide şu çağrı kullanılabilir:

Ruby: 
user = User.create!(user_params)
UserMailer.welcome(user).deliver_later

Kullanıcı kaydı başarısız olursa mailer çağrısını çalıştırmayacak şekilde gönderimi başarılı kayıt işleminden sonra yapmak önemlidir. E-posta gönderimi ile veritabanı işleminin aynı kesinlikte tamamlanmadığını da unutmayın: kullanıcı kaydı başarılı olup kuyruk veya SMTP işlemi başarısız olabilir.

Geliştirme ortamını ayarlama​


Geliştirme ortamında gerçek alıcılara e-posta göndermeden önce teslimat ayarını kontrol edin. Test sırasında iletiyi uygulama günlüğüne yazdırmak, teslimatı kapatmak veya yakalama amacıyla kullanılan yerel bir SMTP servisine yönlendirmek daha güvenlidir. Gerçek SMTP parolasını proje dosyalarına yazmayın; ortam değişkenleri veya Rails kimlik bilgileri kullanın.

Geliştirme yapılandırmasında temel ayarlar şu mantıktadır:

Ruby: 
config.action_mailer.perform_deliveries = true
config.action_mailer.raise_delivery_errors = true

config.action_mailer.default_url_options = {
  host: "localhost",
  port: 3000
}

perform_deliveries false ise Rails iletiyi oluşturabilir fakat dışarı göndermeyi denemez. raise_delivery_errors true olduğunda teslimat hataları görünür hâle gelir; bu ayar geliştirme sırasında SMTP yapılandırma hatalarını fark etmeyi kolaylaştırır. Uygulamanız e-posta içinde parola sıfırlama veya hesap doğrulama bağlantıları üretiyorsa default_url_options bu bağlantıların hangi alan adı ve portla oluşturulacağını belirler; yanlışsa ileti gider ancak bağlantı yanlış adrese yönlenir.

Üretimde SMTP ayarlarını ekleme​


Üretimde kullanacağınız e-posta sağlayıcısından şu bilgileri alın: SMTP sunucu adı, port, kullanıcı adı, parola, bağlantı şifreleme biçimi ve uygulamanın dışarıdan görünecek alan adı. Bunları üretim yapılandırmasına sabit parola olarak yazmak yerine ortam değişkenlerinden okuyun.

Örnek yapılandırma şöyledir:

Ruby: 
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address: ENV.fetch("SMTP_ADDRESS"),
  port: ENV.fetch("SMTP_PORT", 587).to_i,
  domain: ENV.fetch("SMTP_DOMAIN"),
  user_name: ENV.fetch("SMTP_USERNAME"),
  password: ENV.fetch("SMTP_PASSWORD"),
  authentication: :plain,
  enable_starttls_auto: true
}

config.action_mailer.default_url_options = {
  host: ENV.fetch("APP_HOST"),
  protocol: "https"
}

config.action_mailer.raise_delivery_errors = true

Bu değerleri sunucunun ortamına ekledikten sonra uygulamayı yeniden başlatın; birçok dağıtım ortamında yapılandırma, çalışan süreç başlatılırken okunur. SMTP_PORT değerini metin olarak almak yerine to_i ile sayıya çevirmek gerekir. Sağlayıcınız farklı kimlik doğrulama veya TLS ayarı istiyorsa kendi güncel SMTP bilgilerini esas alın; her sağlayıcı için aynı port ve güvenlik seçeneğini varsaymayın.

E-posta adresinizin From alanını da uygulamanın genel yapılandırmasında belirleyebilirsiniz:

Ruby: 
config.action_mailer.default_options = {
  from: ENV.fetch("MAILER_FROM")
}

Mailer içinde özel bir from değeri verilirse bu varsayılan değer geçersiz kılınabilir. Gönderici alanında alıcının adresini kullanmak yerine, SMTP sağlayıcınızın ve alan adı doğrulama kurallarınızın izin verdiği uygulama adresini kullanın.

Gönderimin gerçekten başarılı olduğunu nasıl anlarsınız?​


İlk kontrol, deliver_now kullanıldığında istisna oluşup oluşmadığı veya deliver_later kullanıldığında kuyruğa eklenen işin başarısız olup olmadığıdır. SMTP sunucusunun iletiyi kabul etmesi, iletinin mutlaka gelen kutusuna ulaştığını kanıtlamaz. Alıcı sunucu iletiyi reddedebilir, karantinaya alabilir veya istenmeyen posta klasörüne taşıyabilir.

Sonucu şu sırayla değerlendirin:
  1. Uygulama günlüklerinde SMTP bağlantı veya kimlik doğrulama hatası olup olmadığını kontrol edin.
  2. Arka plan kuyruğu kullanıyorsanız işin başarısızlık kaydını ve hata mesajını inceleyin.
  3. SMTP sağlayıcısının gönderim etkinliklerinde kabul, reddetme, geri dönme veya şikâyet durumunu kontrol edin.
  4. Test alıcısında iletiyi gelen kutusu ve istenmeyen posta klasöründe arayın.
  5. Gönderici alan adı, DNS kimlik doğrulaması veya sağlayıcı politikası nedeniyle reddedilme varsa SMTP sağlayıcısından hata kodunu ve ilgili ileti kimliğini paylaşarak reddin nedenini sorun; parola gibi gizli bilgileri göndermeyin.
Yerel geliştirmede perform_deliveries = false ise başarılı bir uygulama akışı görmeniz gerçek e-posta gönderildiği anlamına gelmez. Buna karşılık SMTP sunucusunun iletiyi kabul etmesi de son kullanıcının iletiyi gördüğünü kanıtlamaz. Bu iki sonucu birbirinden ayırarak hem uygulama günlüklerini hem de teslimat sağlayıcısının kayıtlarını değerlendirin.
Görülen durumAnlamıSonraki işlem
Mailer istisna veriyorUygulama, SMTP’ye bağlanamıyor veya yapılandırmayı kabul etmiyor olabilir.Sunucu, port, kimlik bilgileri, TLS ve ortam değişkenlerini hata mesajındaki alanlarla karşılaştırın.
Kuyruk işi başarısızGönderim arka plan işleyicisinde tamamlanmamış demektir.Kuyruk sürecini, başarısız iş ayrıntısını ve tekrar deneme politikasını inceleyin.
SMTP kabul etti, ileti görünmüyorİleti sonraki teslimat aşamasında filtrelenmiş, ertelenmiş veya reddedilmiş olabilir.Sağlayıcının teslimat kaydını ve alıcı sunucunun durumunu inceleyin.
İleti yanlış bağlantı içeriyorURL üretimindeki alan adı, protokol veya port yanlıştır.Üretim default_url_options ayarını düzeltip yeni test gönderimi yapın.
Tablodaki durumlar birbirinin yerine geçmez. Örneğin uygulama günlüğünde hata olmaması yalnızca uygulamanın gönderim çağrısını tamamladığını gösterebilir; teslimatın gelen kutusuna ulaştığını göstermek için sağlayıcı kaydı ve alıcı tarafındaki sonuç da gerekir.

En küçük çalışan akış​


Kullanıcı nesnenizin email ve name alanları olduğunu varsayarsak, mailer sınıfı, görünüm ve gönderim çağrısı birlikte şu akışı oluşturur:

Ruby: 
class UserMailer < ApplicationMailer
  def welcome(user)
    @user = user
    mail(to: @user.email, subject: "Hoş geldiniz")
  end
end

UserMailer.welcome(user).deliver_now

Bu kodun beklenen sonucu, Rails’in iletiyi oluşturup SMTP teslimat yöntemine göndermeyi denemesidir. Bir Net::SMTP veya kimlik doğrulama hatası alırsanız sorun genellikle mailer görünümünde değil, SMTP adresi, portu, kimlik bilgisi, TLS ayarı ya da sunucunun erişim koşullarındadır. İstisna oluşmaması durumunda da son doğrulamayı SMTP sağlayıcısının gönderim kaydında yapın.

Sık sorulan sorular​

Parolayı Rails koduna yazabilir miyim?​

Yazmamalısınız. SMTP parolasını ortam değişkeni veya Rails kimlik bilgileri üzerinden okuyun ve günlüklerde parola, erişim anahtarı veya tam SMTP yapılandırmasını yazdırmayın. Sorun araştırırken yalnızca sunucu adı, port, hata kodu ve iş kimliği gibi gizli olmayan bilgileri paylaşın.

deliver_now mı, deliver_later mı kullanmalıyım?​

Kısa ve kontrollü bir işlemde deliver_now daha doğrudan olsa da web isteğini SMTP yanıtına bağlar. Kullanıcı kaydı, parola sıfırlama veya bildirim gibi işlemlerde genellikle deliver_later tercih edilir; bunun karşılığında arka plan kuyruğunun çalışır durumda olması ve başarısız işlerin izlenmesi gerekir.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
Toplam: 1 (Üye: 0, misafir: 0, robot: 1)