Reading around and playing with what I've got, I've concluded that I'm on the right path simply embedding the form(s) like any other:
$builder->add('user', 'fos_user_registration', array(
'label' => 'Sign up',
'error_bubbling' => false
));
And I've been theorising that I'd have to align my validation groups with those of FOSUser?:
public function setDefaultOptions(OptionsResolverInterface $resolver)
{
$resolver->setDefaults(array(
'data_class' => 'ACME\ReviewBundle\Entity\Review',
'flowStep' => 1,
'validation_groups' => array('Registration', 'Profile')
));
}
Perhaps with Default too?:
'validation_groups' => array('Default', 'Registration', 'Profile')
However, the validation is still passing and it falls over at database level, so I'm guessing I need to do something else to assign the validation groups?
Beyond that, I'm also unsure how the processing of this is going to work, I could rip a load of it out of the FOSUser form handler and controller, but this seems a bit wet, and I'm wondering whether there is a better way? It would be nice to have it all reliant on the same logic.
To give some context, I'm using CraueFormFlow and I have a process a user needs to be able to start either authed or not. If they are unauthed, the a later step in the process needs them to either register or login.
I need to retain the data collected prior to authentication, which as far as I see, if I can embed the registration and login forms within my main form, should happen naturally.
Note: I have email confirmation off, so that isn't a concern, and it should be possible to make the entire process linear, with the user coming out authenticated and having had their review submitted.
Turns out that I needed an #Assert annotation, otherwise the validation isn't applied.
Related
I'm finding conflicting information on the standard way to integrate PayPal for what I'm trying to do. This is a somewhat higher level question.
My task: After a non-authenticated user of my app (a 'guest') pays for a booking on PayPal, I need them auto redirected back, where I create a record of this, send appropriate emails, and begin my account creation flow.
I'm leaning towards setting it up as described in this SO answer
It uses the 'paypal-sdk-rest' gem and sends a hash of data to a paypal endpoint like:
values = {
:business => business,
:cmd => '_cart',
:upload => 1,
:return => return_url
}
values.merge!({
"amount_1" => amount,
"item_name_1" => name,
"item_number_1" => id,
"quantity_1" => '1'
})
"https://www.sandbox.paypal.com/cgi-bin/webscr?" + values.to_query
But this appears based on a Railscast implementation from way back in 2008! I have doubts this is still an ideal way of doing it.
Auto return:
1) In the implementation above, I cannot get auto return to work, despite setting it up on my business profile.
2) A static URL is required for the auto return setup on the profile page, but I want to pass dynamic data to the auto return for triggering subsequent actions. Will the return_url specified above override the static URL set on the profile page, is it supposed to (since I can't get it to work I can't test and see)?
3) I've read that auto return won't work if users pay with a CC on PayPal?? If that's true, auto return isn't something I should depend on so I need to find a better implementation.
So maybe I should be using:
1) Instant Payment Notifications (IPNs)
or
2) Payment Data Transfer (PDTs).
Should I be using these, if so, which one? Do they accomplish the same goals?
I really just want the simplest, quickest implementation. PayPal is not the main payment method on my app, and I'm questioning whether I should bother supporting it now, given how dead straightforward other solutions (like Stripe) have been for me by comparison plus a growing task list that needs attention.
Thanks in advance for any guidance offered.
I will recommend you use this gem paypal sdk rest, you can follow all the steps like installing the gem, you run the bundle install command and also the rails g paypal:sdk:install also need to login to developer.paypal.com and create a REST API, because you will need the client_id and client_secret in this section:
PayPal::SDK::REST.set_config(
:mode => "sandbox", # "sandbox" or "live"
:client_id => "EBWKjlELKMYqRNQ6sYvFo64FtaRLRR5BdHEESmha49TM",
:client_secret => "EO422dn3gQLgDbuwqTjzrFgFtaRLRR5BdHEESmha49TM")
Also recommend you to go to the Execute Payment section of the link that i have show you above and click in
Only for Payment with payment_method as "paypal"
then you will see another code so copy and paste it in your app, at the end of that code you will see this
# Create Payment and return status
if #payment.create
# Redirect the user to given approval url
#redirect_url = #payment.links.find{|v| v.method == "REDIRECT" }.href
logger.info "Payment[#{#payment.id}]"
logger.info "Redirect: #{#redirect_url}"
else
logger.error #payment.error.inspect
end
There you cant add this line befose the else statement redirect_to #redirect_url
That line of code will redirect you to Paypal, and when user accept the payment it will redirect you to the return_url you out in this part of the code
# ###Redirect URLs
:redirect_urls => {
:return_url => "http://localhost:3000/payment/execute",
:cancel_url => "http://localhost:3000/" },
You definitely want to use IPN for this. Even with Auto-Return enabled there is no guarantee that the user will make it back to that page, so if you're attempting to handle post-payment processing tasks there you'll run into problems where sometimes the user doesn't make it there so the updates don't occur.
IPN will trigger regardless of whether the user makes it back to your site, so you can be sure it will always run the code as expected. Also, IPN will allow you to correctly handle things like e-checks, where the original IPN would show the payment as pending, and when it clears (or fails) you'd get another IPN with the same transaction ID but an updated status.
IPN also allows you to handle things like refunds, disputes, subscription payments, etc. where a checkout may not have happened, but a transaction of some sort did.
I've got articles that can be shown in lots of different sites. They can either be visible or not.
I've ended up going for a single bitmasked permission field in the article, rather than lots of has_many permissions separate records.
I'm not sure how best to set this field. What I've done so far is write two methods in the article model - one gives you a hash of {1 => 'true', 2 => 'true', 3 => 'false'} - visible or not on site 1, 2, 3. The second method takes a similar hash and sets the permission field correctly.
I can send the permission hash to my view through the controller, and I can make checkboxes that show if the article is visible or not. These appear on a pop up dialog using jquery. I haven't done it yet, but I think I can use javascript to make a hash to send back.
But I don't know how to make the update controller take the hash from the params, send it to my make permission method and then put that into the params again to update my article.
How would I go about doing this? Or am I barking up the wrong tree entirely.
Any ideas?
I would suggest you to create a Site model which reproduces the different sites. This is especially a good thing if there might come up more websites! Then you could build a has_and_belongs_to_many association between the Site and the Article model to commit on which site an article should be displayed!
So I'm writing a Facebook clone for a school project using Rails and I need some way to keep track of which users are logged in. At the moment, I'm a bit time-pressed, so I decided just to update the User model every time they visit a page with a last_seen attribute.
Problem is, the user model requires revalidation to successfully update_attributes. So I'm wondering two things:
Is there a better way to do this that I'm missing?
If not (or if it would take too long) is there a way to bypass the validation?
to 1.: I cant give you an exact answer but I think itwould be better to deal with this problem using a javascript on the clientside with a timer that sends an ajax request all xxx secounds and an action that receives this requests and saves it in a seperate table associated with the User.
to 2.: Yes there are some ways to bypass validations The most pragmatic way is to bypass the :validate => false option when saving the object but then you can use update_attributes:
object.save(:validate => false)
So there is also the possibility to use conditional validations that are only used when a specific condition is complyed. There is a railscast about that => http://railscasts.com/episodes/41-conditional-validations .
I am using Ruby on Rails 3.0.9 and I would like to know "how much can be dangerous" to use the following statement in order to save a record in the database:
#user.save!(:validate => false)
That is, what can happen? For example, can a malicious user to hack something (eg: set some not allowed value) in the database?
Notice: I am referring mostly to the :validate => false part of the above code that makes it possible to skip validation processes.
Can a malicious user 'hack something'? That depends. :validate => false disables any validation logic in the class #user belongs to. If you've mass-assigned the parameters you wanted to update in the normal way, you still get all the escaping which will protect you from SQL injection type attacks.
However if the integrity of the application rests on something on #user being valid, you might be in trouble- think of users setting their own account balances, adding extra subscriptions for free, altering expiry dates etc...
I'm not sure what your application does. Look at the relevant validation logic, question why it's there, then ask yourself what would happen if it were disabled and something broke. In general :validate => false is not a good idea.
My software sends emails for users. I want to show them what the emails will look like before they get sent. However, with ActionMailer conventions, the entire template is in one file. This means the html,head,body tags, etc. Can anyone think of a good way to give my users a preview of what the emails I send out will look like?
Thanks!
I had the same issue. I built out the display with the associated model I was sending rather than in the mailer. I was able to feed sample data or live data to display it to the user.
when it came time to actually send it, I rendered the exact same thing within the mailer view
EDIT:
I apologize for the crap variable names in advance. I am not sure I am allowed to explicitly talk about them :)
Lets say I have a BarMailer function called foo(status,bar)
where status is a test email or a live email and bar is my associated model.
I called deliver_foo("test",bar)
deliver_foo sends out a multipart message so for each part I render_message and pass along variables I need. for example:
p.body = render_message('bar_html', :bar => bar, :other_data => bar.other_data)
so, that render_message is is saying to specifically use the bar_html view (I also have a bar_text for plain text).
this is the contents of my bar_html view:
<%=render :inline => #bar.some_parent.some_other_model.html, :locals => {:other_data => #other_data, :time => Time.now, :bar => #bar }%>
Its a little complicated, but it is based on a template system. By rendering inline everywhere, I am able to use the same code for a number of different functions including previewing and sending. I like this because it becomes a WYSIWIG. No extra code or functionality that could be buggy and muck with the potential output in an email. If it works in one area, it will work in the other. Plus keeping it DRY means I am not going to forget to modify a copy (which I would do frequently, hehe).