I used this solution based on devise_parameter_sanitizer to set some custom attributes to my Devise (User) model and make them available at sign_up and edit forms.
Everything works fine but from time to time (and it happens pretty often) specifically when I sign in, sign out or edit user (so I assume the problem is related to sessions), I get the following error:
Is there any logic that I can add to my code above to present this issue?
I know this was a little while ago but wanted to put an answer here because this actually took me a bit to solve and other people might have a similar issue.
Because you used an initializer to load the User:ParameterSanitizer when you change the application controller or anything that would cause it to reload (because you are in debug mode) the initialization is lost.
This is easy to test to confirm this is what was happening to you:
First: start the server fresh and go to your login page: should work.
Next: modify application_controller.rb (just put a space somewhere and hit save)
Next: visit your login page again (not working anymore) :(
Related
I would like to ask this question to developers who have a good sense of design. I see that whenever a website uses a popup box for their login page, they will always post and then redirect to the next page whether it be content or a dedicated login page for an invalid login error.
I have a client who has been asking to cut out as much page refreshing as possible, including the login function. They would like to see the login error appear on the login popup box without a page refresh.
I have not noticed a web based businesses do this, so I'm wondering if there's a valid reason to avoid this. I personally think that a page refreshing allows users to recognize their input has been registered and the next page appearing will be a solid response to their action either good or bad.
Having no refresh and expecting the user to notice that some error text has appeared seems like a bad idea?
Notes
The question is most likely more appropriate for https://ux.stackexchange.com .
You can find a lot of stuff by searching "ajax logins" in a search engine
There already is this question that might indeed be a duplicate of this one. Since I was not sure and I had already wrote most of this answer before finding that I post it nonetheless.
The title ought to be changed to a question (maybe something like "Is it a bad idea to use ajax to return login errors?").
Actual Answer
In my opinion ajax logins could indeed make less clear whether there really has been a successful interaction with the server or not.
Some ideas to improve it might be:
to include the time of the login request in the error message
to explicitly assure in the error message that the credentials have been received and checked
to be sure that this error does indeed only occur after the credentials have been determined to be not valid (and not because of problems with scripts or the network, for example).
A good way to ensure this might be to have the server always send the full text of the error, rather than a code that selects a message stored in the page source (and to be careful its caching).
This becomes relevant only after the user has been using the site for some time, of course (and has incurred in the error and verified that it was indeed due to a mistake on his part).
to use some animated feedback to highlight the dispatch and the reception of the reply to the user. As with the text you should ensure that the animations do not give (too) incorrect indications.
Basically these suggestions would be applicable to any ajax form entry, but they are more important for logins because:
in this context it's a lot easier to make typing mistakes (in the typing of the password)
and mistakes have a drastic, immediate annoying outcome: the inability to authenticate and the necessity to input again the entire password
And so uncertainties on whether the input has really been received and processed are a lot more bothering.
All in all anyhow it's pretty complex to do this well, with both an appealing appearance and a reassuring feedback.
The ones ajax logins that I've incurred into did not do a good job (I think I have indeed experienced false login errors with them).
You can find several ajax login frameworks/plugins by searching for "ajax logins". I have not looked into any of them.
I'm trying to a CSRF protection to an existing MVC4 web application which uses DevExpress grids. I've added the Html.AntiForgeryToken() into the forms on the aspx pages (which contain ascx as partials containing the grids) and can see the __RequestVerificationToken and it's value clearly in developer tools when a save is called.
I've tried commenting out all my ValidateAntiForgeryToken attributes bar one - I went with the delete post method for simplicity (And also to eliminate the DevExpress grids messing with it) and I still keep coming up against this error:
There was a HttpAntiForgeryException
Url: http://localhost:54653/Users/Delete/f86ad393-0039-44e8-beed-a66dbab9266e?ReturnURL=http%3A%2F%2Flocalhost%3A54653%2FUsers
The exception message is
The required anti-forgery form field "__RequestVerificationToken" is not present.
Does anyone have any idea why this might be happening? Could it be that the error is non-descriptive and it's actually that the token doesn't match rather than that it doesn't exist? In previous answers to this question people just say "oh, you have to add the token," which is obviously not helpful here.
Are you submitting the form manually through Ajax? If that's the case, you need to pass the anti forgery token as another parameter with the name "__RequestVerificationToken".
Point 1 : Make sure if your application is has https secure protocol. Please load in https.
Point 2 : In case of DevExpress you have to call in the below pattern.
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
After struggling with this for days I had a thought - maybe the browser is stopping the cookie being written. I did a search for dev servers and cookies not being written, and found that with Chrome and IE10 and up that there's problems writing the cookies.
I downloaded Firefox and tried it with that and it worked instantly. I then reapplied all the validate attributes to the all the controller methods and the all worked, every single one of them! Even the DexExpress postbacks seem to be working correctly.
I'll carry out more exhaustive testing, but for now, I think we're there.
Not exactly. If MVC AntiForgeryToken is already defined on page where you are using MvcxGridView and you want to protect grid actions you should send this token back to server during grid client side begin callback event.
settings.ClientSideEvents.BeginCallback = "function(s,e) { e.customArgs[\"__RequestVerificationToken\"] = $('input[name=\"__RequestVerificationToken\"]', $(s.GetMainElement())).val(); }";
This is more of a design question.
I figured out how to use the facebook login via the Facebook SDK c#.
QUESTION: What is the best way to check whether the user is logged into FB or not each time the user goes to a different page?
Back on ASP.NET webforms, I could simply put in code to check FB login status in the code behind of a master page. This was good ... once and done. But I don't understand how to implement something similar in Asp.Net MVC 4.0.
Given that the _Layout.cshtml file (which acts like a master page) is only a view (hence, no code behind), what is the best way to code a way to check if the user is logged into FB each time a user goes to a different web page? Because I would think, adding this bit of code to each controller can't be the optimal design solution.
The only solution that I can think of involves using Javascript on the client side to do a WebApi call ... I guess the script will be bundled with all the other scripts so that it runs on each page. But I was hoping to find a solution on the server side ...
I'm pretty new to MVC, learning things as I go along ... tips appreciated ... thanks!
I can think of a couple of points that might help you devise a solution.
You can put code in your _Layout, but I agree that you want to be careful about doing so. You could create a helper or partial view and have your _Layout call it so that it's executed for every action. Your helper/partial would need to execute the required logic and then return something. The problem that I have with this is it's a lot of overhead every request.
You could do an AJAX call after the page is loaded (as you suggested). This means that the page still loads quickly. The problem I have with this is that you're now dependant on Javascript. It's also potentially a little hacky(?)
What about storing the user's status (logged on/off) in a session/cookie and also providing a 5 minute expiry. You can use the Helper/Partial method from before or have some logic fire in OnActionExecuting (or similar). Your logic should check to see if the status has expired and then connect to the Facebook API to update the status. This has the advantage of low overhead (i.e. not checking again until 5 minutes has passed).
I don't know of your exact situation so I can't say what method, if any, is best.
Testing and Rspec are new to me. Currently I'm using Rspec with Shoulda and Capybara to test my application. It's all fine to test models, controllers, helpers, routing and requests. But what should I exactly test in views? Actually I want to test everything in views, including DOM, but I also don't want to overdone things.
These three things would be a good starting point
Use Capybara to go start at the root of your site, and have it click on links and whatever until it gets to the view you want tested.
Make sure what ever content is supposed to be on the page, is actually showing up on the page. So, if they 'user' went to the Product 1 page, make sure all the Product 1 content is actually there.
If different users see different content, make sure that's working. So, if Admin users see Admin-type buttons, make sure the buttons are they when the user is an Admin, and that aren't when the user isn't.
Those 3 things are a pretty good base. Even the first one is a big win. That will catch any kind of weird view syntax errors you may have accidentally introduced, as the syntax error will fail the test.
At my work we are using RSpec only to do unit testing.
For business testing or behavior testing we are using Cucumber that is much more readable for the business and IT guys.
It's like a contract that you sign with your business or it's like a documentation that you can execute.
Have a look at Cucumber: http://cukes.info/
I use view specs to verify that the view uses the IDs and classes I depend on in my jQuery code.
And to test different versions of the same page. E.g.:
I would not want to create two full request or feature specs to check that a new user sees welcome message A and a returning user welcome message B. Instead I would pick one of the cases, write a request or feature spec for it, and then a additional view spec that tests both cases.
Rails Test Prescriptions might be interesting for you, since it has a chapter dedicated to view testing.
We have one page that is causing the Session_start to run and I cannot figure out why. Anytime home.aspx is called, Session_start in global.asax is called and a new sessionid is created.
The sessionid looks to be created right when session_start is called. I think that is normal. I just don't know why it is called all from this page.
Home.aspx uses a different master page than the others. I have not found anything in it that is causing this. I checked the Response.Redirect calls, because others have indicated that could be the issue. I found none being called.
Using firebug, I found this:
Server Microsoft-IIS/5.1
.
.
Location /ent4_sql/(S(unfzfplfp5ltgxcrtpt2bk3f))/Home.aspx?_TSM_HiddenField_=ctl00_ctl04_HiddenField&_TSM_CombinedScripts_=%3b%3bAjaxControlToolkit%2c+Version%3d4.1.40412.0%2c+Culture%3dneutral%2c+PublicKeyToken%3d28f01b0e84b6d53e%3aen-US%3aacfc7575-cdee-46af-964f-5d85d9cdcf92%3ade1feab2%3af9cec9bc%3aa67c2700%3af2c8e708%3a8613aea7%3a3202a5a2%3aab09e3fe%3a87104b7c%3abe6fb298
The session in the url is different than the one that is displayed in the browser address bar. The browser seems to always keep the original.
From searching the web, this issue seems to be one that doesn't really have a direct answers. I am just out of things to look for. Any suggestions would be helpful.
Update***
Using fiddler, I found that the system is actually going to ent4_sql/Home.aspx?.....
Notice the session is not in the URL
That displays a page
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
and seems to redirect whatever is calling that to a url with session. I am trying to find more information on if others have seen the AjaxControlToolkit doing this.
The problem had to do with the Ajax Control Toolkit and cookieless sessions, as expected. Here is an issue reported in 2009 dealing with the same problem. Fix is now included on the issue
http://ajaxcontroltoolkit.codeplex.com/workitem/23443