Posted in Scala

Receiving Mail in Scala

On recent project I had the need to read emails from my app so I thought I’d share a sample. This problem fits neatly into the construct of an Akka Actor.

import javax.mail.internet.MimeMessage
import javax.mail.{Folder, MessagingException, NoSuchProviderException, Session}

import actor.MailReceiverActor.Check
import akka.actor.{Props, Actor}

class MailReceiverActor(host: String, port: Int, user: String, password: String, inboxName: String) extends Actor {

  override def receive: Receive = {
    case Check =>
      val props = System.getProperties
      props.setProperty("mail.store.protocol", "imaps")
      val session = Session.getDefaultInstance(props, null)
      val store = session.getStore("imaps")
      try {
        store.connect(host, port, user, password)
        val inbox = store.getFolder(inboxName)
        inbox.open(Folder.READ_ONLY)
        inbox.getMessages map {
          case message:MimeMessage => processMessage(message) // define this function to handle the message
          case _ => // do nothing or log that you only process MimeMessages
        }
        inbox.close(true)
      } catch {
        case e @ (_:NoSuchProviderException|_:MessagingException) => // log the error
      } finally {
        store.close()
      }
  }
}

object MailReceiverActor {
  case object Check

  def props(host:String, port:Int, user:String, password:String, inboxName:String) = {
    Props(new MailReceiverActor(host, port, user, password, inboxName))
  }

}

Then to use this Actor you can just create a schedule for how often the mail will be checked. In play you can place this in the onStart of Global.

val system = Akka.system(app)
val mailActor = system.actorOf(MailReceiverActor.props(host, userId, user, password, inboxName))

implicit val executionContext = // user defined or use the default play context
system.scheduler.schedule(5.seconds, 20.minutes, mailActor, MailReceiverActor.Check)
Posted in Scala

Registration and Login with Play 2.3 Revisted (Silhoutte)

My early attempts for play login/rego were using SecureSocial. SecureSocial looked promising. It was providing good support for the features I wanted and getting a simple implementation up and going worked relatively easily.

Its only when I start going past the initial simple implementation that it started to give me real problems. The version for Play 2.3 is still immature and there isn’t enough documentation on the interfaces that you need to implement. Customising the user services to get user login and registration working with an existing backend takes too long and leads to hard to debug errors. In conclusion, it just isn’t worth the headache. The library makes life harder.

So I’ve now moved to Play Silhoutte. It is actually a fork of SecureSocial. The author behind it forked it for a lot of the same reasons that I dislike SecureSocial. Silhoutte is more modular, simpler to customise and has good documentation. There is also plenty of activator seed projects that prove how it works and how to customise it.

The Silhoutte Slick Seed provides a good example project that shows how to integrate with your own backend.