So I have two Rails applications. The old one is using devise (2.2.1) for authentication and the new one has devise (3.2.4). There is a huge amount of users (nearly 10k) in database.
Rails version of the old app is (3.2.11), the new one is (4.0.2).
What I need is to 'copy' every user from the old app to the new one.
And so I did. But now when I'm trying to log in it fails. Here's some logs:
Started POST "/users/sign_in" for 185.16.106.233 at 2014-05-09 06:45:24 +0400
Processing by Devise::SessionsController#create as HTML
Parameters: {"utf8"=>"?^?^?", "authenticity_token"=>"8d8yWlLPNcaITv5WqT5fgooAQCUOY6DIC1HiZPgslXM=", "user"=>{"email"=>"test.for.stats#gmail.com", "password"=>"[FILTERED]"}, "commit"=>"Log in"}
Completed 401 Unauthorized in 16ms
I think there's a problem with password encryption. I tried to copy secret_token and pepper from the old app devise, but it didn't help.
Any ideas how to resolve this without mass password reset?
Thanks.
Related
I created a Ruby on Rails API with a group of people via Github. For some reason, my authorization fails repeatedly and says the following in my server.
Started GET "/boards" for ::1 at 2020-08-24 21:38:38 -0400
Processing by BoardsController#index as */*
Filter chain halted as :authorized rendered or redirected
Completed 401 Unauthorized in 1ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 150)
Any ideas on what may be happening here? Boards is a controller I created and I am trying to index it. It additionally doesn't work with a post method either.
You're almost certainly either not sending any credentials in your requests from Postman, or the credentials you are sending are incorrect.
You can see information about making Postman send credentials as part of your request in the Postman docs at https://learning.postman.com/docs/sending-requests/authorization/
In order to know what you need to send, you would need to know what authentication mechanism you're using. With an API, this is most likely a JWT and you are most likely using the Devise gem, but something else may have been configured in your app.
In the case of it being JWT, you would need to generate a valid JWT in your application, then configure Postman's authorization to use "Bearer Token", providing the token you generated as the value there
Does shopify have a method of authenticating requests to my postgresql db. I was given code to a shopify embedded app done using ruby on rails (backend) and react.js with Polaris (front end) and I see that the front end makes requests to the backend without any headers or authorization.
Example:
axios.get('/api/main/vendor’)
.then(response=> {
console.log(response)
})
.catch(error=> {
console.log(error)
});
This seems to work and print outs the response from the backend.
However, when I run the server and make the GET request through Postman, passing in this URL:
https://<NGROK_URL>/api/main/vendor
I can see in my terminal that I get status 302 (redirected to login).
Processing by Api::MainController#vendor as JSON
Redirected to https://<NGROK_URL>/login
Completed 302 Found in 19ms (ActiveRecord: 0.0ms)
I’m wondering if there’s some sort of authentication that shopify does when developing an embedded app that I’m unaware of. For example does it implicitly pass in some token? If so, where can i find this. Sorry for this question if it sounds newby, I’m pretty new to shopify dev.
Shopify usually passes a hmac argument that needs to be validated in the backend.
This hmac includes mostly static information like your store name, timestamp, language etc... but the important part is that is salted with the APP password.
You can read more about this here: https://help.shopify.com/en/api/getting-started/authentication/oauth#verification
This means that you can't make requests outside of Shopify.
I am working through the Ruby on Rails 'Getting Started' guide. In section 9 we attempt to add basic authentication to the controllers to disallow actions such as updating a blog article and deleting blog comments.
The guide says to use the following code at the top of the article_controller class
http_basic_authenticate_with name: "dhh", password: "secret", except: [:index, :show]
Doing so and then attempting to update an article (or any of the blocked actions) causes seemingly nothing to happen on the browser (no authentication prompt) however when viewing the output from the rails server command in the terminal I get the following request data repeated until I close the page:
Started GET "/articles/3/edit" for 127.0.0.1 at 2014-09-04 15:41:39 +0100
Processing by ArticlesController#edit as HTML
Parameters: {"id"=>"3"}
Filter chain halted as #<Proc:0x007fc5d915e6f8#/Users/Ben/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/actionpack-4.1.5/lib/action_controller/metal/http_authentication.rb:71> rendered or redirected
Completed 401 Unauthorized in 1ms (ActiveRecord: 0.0ms)
I have followed the guide to the letter thus far with no issues. I have noticed a number of similar questions to this online with no answers. None of them included the output from the server so I'm hoping this might give a clue as to the cause.
Thanks in advance for any help.
sometimes I've faced problems due to mistakes in the rails's getting started guides. I often use the following code to the http basic auth:
before_filter :require_http_basic_auth, :except => [:index, :show]
def require_http_basic_auth
# code
end
The following question addresses a similar problem rails authenticate_or_request_with_http_basic.
Check the answer to this question. It might help you understand what is exactly happening.
We are currently having a very strange issue that is occurring with a Spree install running on NGINX. Users are reporting issues recovering passwords and once recovered having issues of logging into the site. We have not been able to reproduce this error but know it is certainly happening due to all of the reports from users we are receiving. Also to not is users are able to login when they try a different browser. If the first attempt is in Firefox and then they try Chrome chrome will end up working in a good amount of cases.
Email from user:
"Still not getting through to shop. I have changed my password twice now and when I got to put it in nothing happens. It just refreshes the page and I am left with a blank spot for e-mail and password. "
Errors in the NGINX error log:
cache: [GET /login] miss
cache: [POST /user/sign_in] invalidate, pass
Configuration:
Rails 3.1, Spree 1, passenger-3.0.11, ruby 1.8.7 REE
Any and all answers / suggestions are GREATLY appreciated.
Two rails applications were running on both a domain and a subdomain and the browser had conflicts with the session cookie set in the file session_store.rb that had the same key and would not allow users to login if they had the cookie from sample-domain.com first or shop.sample-domain.com respectively.
As it says in the subject, I'm just finishing up integrating Devise authentication into a Rails 3.1 app with Jquery Mobile. Most everything here is straight out of the box, no custom code, so there's not a lot I can paste in here to add to the description of the problem.
When a user fails the Sign Up process because of a pre-existing email address, password not long enough, etc., a message is displayed to the user. It isn't pretty, but it at least works.
However when the user has an existing account and types the wrong password during sign in there is no feedback to the user and the console outputs the error:
POST http://localhost:3000/users/sign_in 401 (Unauthorized)
I've got a pretty strong suspicion that this is happening because Jquery's form submit does not expect or know how to handle a 401 error returning from the server, but I'm not certain where to resolve the issue.
If it matters, I have uncommented the following in the Devise initializer:
config.http_authenticatable_on_xhr = true
I'm also expecting that much of my problem here stems from my lack of understanding about how Rails flash notices are (or are not) integrated in JqueryMobile. Hopefully an answer here will take me that much further towards figuring it out.
jQuery Mobile 'takes over' your form submissions. However, you can simply override this behavior by adding your own form submit listener. If you do that, you should be able to add any custom logic you want.