I'm playing around with writing a pure Ember.js app on top of Rails 4 and I'm puzzled how user management is handled. My original idea was to use pure server-rendered templates (ERB) to do the user registration and login via Devise, and then the rest of the app would use the Ember framework.
The problem with that is that Ember wants to take over the <body> tag and control the entire viewport. In this way I can't pick and choose which aspects of the app should use server-rendered Erb templates and which should live in the Ember logic.
I see plenty of examples of how to deal with a user that's already logged-in and ember-auth looks interesting to facilitate authentication-aware controllers, but I've seen no tutorials or suggestions on allowing the full user signup experience to take place in the Ember app.
Am I missing something, either from a technical perspective where I just haven't found the right code or from a architectural perspective where I shouldn't be doing it this way?
This is with ember-rails (0.12.0 w/1.0.0.rc3.3 ember-source), Rails 4.0.0.rc1, and Devise (rails4 branch).
ember-auth dev here.
You don't actually need any special treatment for user sign up. Treat user sign up as you would for another model, in the sense that creating a user model will not require authentication. (Editing it or deleting it should require authentication though.)
Your implementation might look like:
App.User = DS.Model.extend
email: DS.attr 'string'
password: DS.attr 'string'
App.UsersNewRoute = Em.Route.extend
model: ->
App.User.createRecord()
App.UsersNewController = Em.ObjectController.extend
create: ->
#store.commit()
Error-checking, template code, etc, skipped for brevity.
This is here for reference to what worked based off of #heartsentwined's answer since pasting in comments doesn't work very well. See the comments for more info. Since my api returns the user json I just pass in the format its expecting.
didCreate: function() {
var user = App.Auth.get('_response').response.user;
var auth = {auth_token: user.auth_token, id: user.id};
App.Auth.get('_response').canonicalize(auth);
App.Auth.trigger('signInSuccess');
}
UPDATE:
I switched to ember-model and now do this in the same place that I call model.save() (the submit action of SignupController).
var model = this.get('model');
model.on('didCreateRecord', function() {
var user = this.data;
var auth = {auth_token: user.auth_token, user_id: user.id, remember_token: user.remember_token};
App.Auth.get('_response').canonicalize(auth);
App.Auth.trigger('signInSuccess');
});
model.save();
The solutions above ALMOST but not quite worked for me. Here is what did work:
didCreate: function() {
var user = App.Auth.get('_response').response.user;
App.Auth.signIn({
data: {
'email': user.email,
'password': this.get('password'),
'remember': true
}
});
}
App.Auth.signIn is used in the documentation explicitly: http://ember-auth.herokuapp.com/docs
Related
I'm using Devise, but not using the Devise controllers directly because I'm performing all of the actions through a custom built GraphQL API. One issue I have, for example, is that after enabling confirmable, if a user tries to sign in and I call Devise::Controllers::Helpers#sign_in the user gets redirected to /api/v1/users/sign_in, which doesn't exist and it would be wrong even if it exist. Instead, I need the failure to sign in to be returned back to my code (return value, exception, whatever), so that my API can encode that response to the frontend.
How can I do that?
For example, this is my log in function:
def resolve(email:, password:)
user = User.find_for_authentication(email: email)
if user&.valid_password?(password)
context[:sign_in].call(user)
{ current_user: user }
else
{ errors: [{ message: 'Email or password incorrect.' }] }
end
end
context[:sign_in] is set up in the GraphqlController by including Devise::Controllers::Helpers and then simply:
context = {
current_user: current_user,
sign_in: method(:sign_in),
sign_out: method(:sign_out)
}
Note: I am not using GraphqlDevise because I don't want to use Devise Token Auth, I'm using cookies.
I believe passing devise's sign_in/sign_out methods via context is probably a deadend.
The suggestion in the comment to your question from #Int'l Man Of Coding Mystery is good ie you could use: https://github.com/graphql-devise/graphql_devise.
If you're not keen in introducing another dependency and figuring out how to wire everything you can perhaps go with overriding devise's SessionController.
See for some examples here: Rails - How to override devise SessionsController to perform specific tasks when user signs in?
(but also don't hesitate to look at the source code for the matching Devise release: https://github.com/heartcombo/devise/blob/master/app/controllers/devise/sessions_controller.rb)
Depending on your use case you might be even able to do what you need by using some of the config options - e.g. you can perhaps try to override after_sign_in_path etc.
I'm kind of a newb to RoR and I'm working on creating my first web app.
So...My question is, how do I create a user time sheet in RoR?
What I need to do is create a classroom time sheet for students' (Users) reading times at home.
The students (Users) are able to sign up and have a profile created. From there, I would like for them to have access to log in their reading time(s).
I have attached examples of just some simple timesheets that would work perfectly for this.
I just do not know where to start and have not been able to find any gems that could help me create this.
Time Sheet 1
TimeSheet 2
Users: Ruby part
Use Devise gem - it will save a lot of time for you.
Add Devise to user model (something like that: rails generate devise User), then autogenerate basic Devise pages (sign in, sign up, etc), see Devise tutorials:
https://launchschool.com/blog/how-to-use-devise-in-rails-for-authentication
http://guides.railsgirls.com/devise
Also you'll probably need something like Job model with fields user_id, time_spent, date or something.
Timesheets: JS part
Time tracking is more front-end part of work, so you'll need to write some JS scripts for time tracking, which will monitor user activity and then send it to Job mobel on Rails side.
Track time spent on page (example):
var page_opened;
$(document).ready(function () {
page_opened = Date.getTime();
$(window).unload(function () {
page_closed = Date.getTime();
$.ajax({
url: "/save_user_time",
data: {
'timeSpent': page_closed - page_opened,
'job_id': job_id
}
})
});
}
Also you defenetly should take a look on some basic Rails tutorials for better understanding:
http://guides.rubyonrails.org/getting_started.html
https://www.codecademy.com/learn/learn-rails
I'm looking to satisfy 3 goals with my Ember.js app authentication using rails, devise and a cookie based session.
Redirected to #/sessions/new if they're not logged in.
Always show the current user's information in the application template.
If the user is logged in and they go to #/some/route directly. The current user should be loaded on load.
I've watched these embercast videos: Client-side Authentication Part 1 & Client-side Authentication Part 2. They're a little out of date but helpful.
But still can't full solution. Anyone have full Rails 4, Devise, Emberjs 1.0.0 example?
Biggest problem is having a strategy to load the current user on page load and setting the current user when the sign in form is submitted.
Right now this is my strategy:
App.User = Em.Object.extend();
App.User.reopenClass({
current: function() {
return Ember.$.getJSON("/users/current").then(function(data) {
return data
})
}
});
App.ApplicationRoute = Ember.Route.extend({
model: function() {
return App.User.current();
}
});
App.SessionsNewController = Ember.ObjectController.extend({
actions: {
save: function(data) {
var self = this, data = this.getProperties('email', 'password');
$.post("/sessions", { session: data }).always(function(response, status, data) {
if (status == "success") {
self.transitionToRoute('index');
} else {
self.set('errorMessage', data);
}
})
},
}
});
I would not say this is not doable. But you will do lots of extra and unnecessary works to get the authentication working, which can all be done with a simple page redirect.
I've collected some opinions from Derick, the author of Backbone.Marionette. Though these are for Backbone but not Ember.js, the situation of client side authentication is same.
I find it painful and unnecessary to try and make Backbone/Marionette handle the authentication and re-loading of the authorized site stuff. Once they log in, redirect them to a different URL that the server handles, and have the server send down all the stuff that they need, as an authenticated user. https://stackoverflow.com/a/18151935
Another quote from Derick as well:
Right. And there’s a lot of cases where I just flat out say, “Do not do single-page applications,” as well. And a login screen is the biggest example of that. In all of the clients that I’ve had in the last couple of years, they’ve all asked me, “Hey, I’m having this problem. I’m trying to get my login screen to give me the current user information back from the server and redo all of this stuff on the screen without refreshing everything.” My answer every single time is, “Don’t do that." http://javascriptjabber.com/056-jsj-marionette-js-with-derick-bailey/
Also think about other cases, say Gmail. You won't get a smooth transition after click "Sign in" button on Gmail's sign in page. There will be redirect with rather big data loading as well :)
From users' perspective, they won't say Gmail is not great just because there is a redirect after signing in. After all signing/sign up is much much less frequent than daily mail operations.
So my suggestion is, reload all resources after user session changed. Let Rails and Devise do these dirty jobs in traditional fashion.
I am in the process of building a facebook app that works through iFrame with Ruby On Rails.
My App does serve multiple clients, web, mobile, and facebook. And depending the type of client the UI renders different kind of views.
When the user connects to my app using the facebook page tab, I do get enough information (in params collection) to identify the user came from facebook. Based on that I can customize the views to fit into the iFrame.
But for subsequent requests, because they happens through iframe, there is nothing that tells this is a facebook request (as far as I can tell unless there is something in the headers which I dont know of).
I tried setting a cookie during the first request and that worked great. But the problem is when the user requested my app directly from another browser tab (not through facebook) the cookie was still present and the user ended up seeing the facebook(ised) UI, instead of Normal UI.
Anyone has a solution to this?
I recommend using a different route for Facebook tabs. So if your regular URLs look like this:
/foobar
Then you may want to use something like this for Facebook, by adding the "/fb" prefix (or similar) to your Facebook app's tab or canvas URL:
/fb/foobar
In your routes.rb, you can then pass a parameter to indicate that the user is viewing the page on Facebook, such as "channel=facebook" or "facebook=true".
Your routes.rb might look something like this:
scope 'fb', :channel => 'facebook' do
# ... your routes ...
end
scope :channel => 'web' do
# ... your routes ...
end
With these routes, each request originating from Facebook will automatically have a "channel=facebook" parameter. Of course, you'd still be responsible for making sure to generate the appropriate URLs within your app. You could add :as => 'facebook' and :as => web to the scopes above and use this to generate URLs using dedicated helpers (e.g. facebook_foobar_url, web_foobar_url). But the best way to do this depends a lot on the complexity of your app.
Alternatively, you could also use default_url_options in your controller to add a "channel=facebook" or "facebook=true" parameter to every generated URL if you detect that the current request originated from Facebook (either from the existence of a signed_request or from channel/facebook param you added). Note that this method is deprecated in Rails 3, and I'm not quite sure what (if any) the official replacement is in Rails 3.1 or 3.2.
I needed to solve this with the least amount of intrusion into the existing code.
And am posting my solution here for the benefit of anyone looking to solve similar problem.
I have a unique layout for facebook and this was invoked during the first request (like I mentioned above, the initial request posted from facebook tab has facebook params).
To make sure there was facebook param for subsequent requests, inside the facebook layout, I bound all the form submission and anchor click events to a method that would add a hidden form element and query string param respectively.
this is how the client side code looks like:
<script type="text/javascript">
$(document).ready(function() {
$('form').submit(function(e) {
$('<input>').attr({
type: 'hidden',
id: 'fb_param',
name: 'fb_param',
value: 'true'
}).appendTo($(this));
return true;
});
$('a').click(function(e) {
var newUrl = $(this).attr("href");
if (newUrl.indexOf("?") != -1) {
newUrl = newUrl + '&fb_param=true';
} else {
newUrl = newUrl + '?fb_param=true';
}
$(this).attr("href", newUrl);
return true;
});
});
</script>
Now to handle the server side redirects (typical when you update a resource etc), needed to extend the redirect_to method like so:
/app/conntrollers/application_controller.rb
class ApplicationController < ActionController::Base
def redirect_to(options = {}, response_status = {})
if params[:fb_param] == 'true'
if options
if options.is_a?(Hash)
options["fb_param"] = "true"
else
if options.include? "?"
options = "#{options}&fb_param=true"
else
options = "#{options}?fb_param=true"
end
end
end
end
super
end
end
I've been attempting to hook a Rails application up to ActiveDirectory. I'll be synchronizing data about users between AD and a database, currently MySQL (but may turn into SQL Server or PostgreSQL).
I've checked out activedirectory-ruby, and it looks really buggy (for a 1.0 release!?). It wraps Net::LDAP, so I tried using that instead, but it's really close to the actual syntax of LDAP, and I enjoyed the abstraction of ActiveDirectory-Ruby because of its ActiveRecord-like syntax.
Is there an elegant ORM-type tool for a directory server? Better yet, if there were some kind of scaffolding tool for LDAP (CRUD for users, groups, organizational units, and so on). Then I could quickly integrate that with my existing authentication code though Authlogic, and keep all of the data synchronized.
Here is sample code I use with the net-ldap gem to verify user logins from the ActiveDirectory server at my work:
require 'net/ldap' # gem install net-ldap
def name_for_login( email, password )
email = email[/\A\w+/].downcase # Throw out the domain, if it was there
email << "#mycompany.com" # I only check people in my company
ldap = Net::LDAP.new(
host: 'ldap.mycompany.com', # Thankfully this is a standard name
auth: { method: :simple, email: email, password:password }
)
if ldap.bind
# Yay, the login credentials were valid!
# Get the user's full name and return it
ldap.search(
base: "OU=Users,OU=Accounts,DC=mycompany,DC=com",
filter: Net::LDAP::Filter.eq( "mail", email ),
attributes: %w[ displayName ],
return_result:true
).first.displayName.first
end
end
The first.displayName.first code at the end looks a little goofy, and so might benefit from some explanation:
Net::LDAP#search always returns an array of results, even if you end up matching only one entry. The first call to first finds the first (and presumably only) entry that matched the email address.
The Net::LDAP::Entry returned by the search conveniently lets you access attributes via method name, so some_entry.displayName is the same as some_entry['displayName'].
Every attribute in a Net::LDAP::Entry is always an array of values, even when only one value is present. Although it might be silly to have a user with multiple "displayName" values, LDAP's generic nature means that it's possible. The final first invocation turns the array-of-one-string into just the string for the user's full name.
Have you tried looking at these:
http://saush.wordpress.com/2006/07/18/rubyrails-user-authentication-with-microsoft-active-directory/
http://xaop.com/blog/2008/06/17/simple-windows-active-directory-ldap-authentication-with-rails/
This is more anecdotal than a real answer...
I had a similar experience using Samba and OpenLDAP server. I couldn't find a library to really do what I wanted so I rolled my own helper classes.
I used ldapbrowser to see what fields Samba filled in when I created a user the "official" way and and basically duplicated that.
The only tricky/non-standard LDAP thing was the crazy password encryption we have:
userPass:
"{MD5}" + Base64.encode64(Digest::MD5.digest(pass))
sambaNTPassword:
OpenSSL::Digest::MD4.hexdigest(Iconv.iconv("UCS-2", "UTF-8", pass).join).upcase
For the def authenticate(user, pass) function I try to get LDAP to bind to the domain using their credentials, if I catch an exception then the login failed, otherwise let them in.
Sorry, cannot comment yet... perhaps someone can relocate this appropriately.
#Phrogz's solution works well, but bind_simple (inside bind) raises an Net::LDAP::LdapError exception due to auth[:username] not being set as shown here:
https://github.com/ruby-ldap/ruby-net-ldap/blob/master/lib/net/ldap.rb
The corrected replaces:
auth: { method: :simple, email: email, password:password }
with:
auth: { method: :simple, username: email, password:password }
I began using ruby-activedirectory, and even extended it/fixed a few things, hosting judy-activedirectory in Github.
Doing the next iteration, I've discovered ActiveLdap has a much better code base, and I'm seriously contemplating switching to it. Does anyone have personal experience with this?
Have you checked out thoughtbot's ldap-activerecord-gateway? It might be something for you to consider...
http://github.com/thoughtbot/ldap-activerecord-gateway/tree/master