Error with Devise devise-2.1.0 #21
Comments
Does devise store the ids in the session without converting them to strings by chance? |
it seems yes for devise-2.1.0 the @ data keep returning [79, 121, 120, 189, 5, 9, 112, 160, 43, 0, 0, 11] for not login user I am still testing new devise-2.1.0 with mongoid 3.rc, i shall give you update when bugs free. if it is global issue in devise, i shall post them suggestion. |
I'm not sure who's problem it is, but the ids should definitely be getting stored as strings in the session, not as some form of serialized output, probably yaml. But we should handle this gracefully somewhere. Your solution won't give an error, but won't actually find the right user since you're generating a new id instead of using the one that was supposed to be represented there. |
I think the patch above is working smooth, i have no problem with devise any more and work smooth in multi-users. I understand that patch isn't appropriate solution as your worried, but that is only and if only the instance variable data returns Array which is not expected Object Type in your moped object_id. I think you should put solution for unexpected data type instead of throwing error. |
Yeah I will put something in to handle this gracefully, I just need to dig down into the rack session to see if it's using anything specific for marshall/unmarshall. |
Not sure this should be closed given it's still an issue; I imagine this is potentially going to impact a lot of people given devise is pretty standard these days. Just upgraded to Mongoid 3 and ran into this; a fix would be smashing. |
@JamesHarrison : I used Mongoid 3 when headed with this issue. Upgrading to mongoid 3 from 2.x.x version, I think it could give new problem, because new version condition might be not suitable with old mongoid version. For temporary solution, people only need to create patch monkey on lib folder, like i did. |
I think Devise is also storing the authenticated resource in the session; when switching between Mongoid 2.4.x and 3.0.0 on our staging environment, we get a lot of these errors and everyone has to clear their cookies. FYI to others who might be similarly effected. Below is when we downgrade from 3.0 to 2.4.
|
Object ids no longer leak internal information when marshalled. Additionally, data is now silently upgraded to the correct format, both from Moped's previous string data representation, and the mongo-ruby-driver's data array format. [fixes: issue #21]
Okay. Moped's object ids are now marshal-aware, using a much better marshalling strategy than previously. Additionally, all previous formats -- both string and the array -- should be silently upgraded. |
Hmmm... I'm seeing a similar problem, but not exactly that:
Happens because warden in mongoid2 was storing the BSON::ObjectId('...') but then when you upgrade to mongoid3 you no longer have that object. |
@tobowers If you don't have the 10gen driver in the application, can you try doing: BSON = Moped::BSON somewhere in your app and see if that helps? |
@durran Thanks, though: We actually use the mongo driver in a gem in our app... so not ideal. Any other recommendations? I guess we could change that gem to use moped but it would be more of a PITA. I might be able to scope that constant in a rails app by putting it in the ApplicationController - I'll give that a shot. |
Should moped do this automatically when BSON is not defined? -a On Aug 7, 2012, at 13:31, Durran Jordan notifications@github.com wrote: @tobowers https://github.com/tobowers If you don't have the 10gen driver BSON = Moped::BSON somewhere in your app and see if that helps? — |
@ahoward Would be nice if it did, but due to no control over the order in which gems are loaded we cannot absolutely guarantee that if BSON is not defined the bson gem was not in the Gemfile or required later on, etc, etc so there's no definite there. @tobowers It's a tricky situation to try and resolve. The core problem is when object ids get stored in the session without calling #to_s on them, so they get marshaled. Devise needs to fix this, since it's just bad practice to begin with and also a performance hindrance. I don't have any other recommendations at the moment, but I will see if I can come up with something tomorrow. |
@durran - const_missing or autoload would do it. autoloading moped/bson_shim.rb with a BSON = Moped::BSON is relatively benign.... also magic. but lots of code expects top level BSON, OTOH |
@tobowers perhaps monkey-patch with an appropriate def of 'bson_dump' somewhere... |
@tobowers You could try having BSON::ObjectId implement bson_dump and redirect it back to Moped::BSON::Object. It's somewhat ugly but it could route around the issue. unless BSON::ObjectId.instance_methods.include?(:__bson_dump__)
module BSON
class ObjectId
def __bson_dump__(io, key)
# construct a Moped BSON Object Id
obj_id = Moped::BSON::ObjectId(self.to_s)
obj_id.send :__bson_dump__, io, key
end
end
end
end |
were there any workaround for this issue ? I'm having it in the middle of a migration to monogid 3.x in production now. |
@alduro You can do what @durran suggested by "redirecting" the BSON namespace to Moped::BSON. Or if you need to have Mongo's BSON around, then you will need to do what I suggested. |
@callumj Thanks ! Where did you put your solution ? under lib/bson/object_id.rb ? |
@alduro I'd put in the root of lib and name it something that communicates that it is monkey patching BSON eg: 'lib/bson_extensions.rb' It may be better to wrap it in a module and then extend ObjectId (calling it lib/object_id_extensions.rb) module ObjectIdExtensions
def __bson_dump__(io, key)
# construct a Moped BSON Object Id
obj_id = Moped::BSON::ObjectId(self.to_s)
obj_id.send :__bson_dump__, io, key
end
end
unless BSON::ObjectId.instance_methods.include?(:__bson_dump__)
BSON::ObjectId.class_eval do
include ObjectIdExtensions
end
end |
@callumj got it Thanks ! |
when i called current_user, i got this error message "can't convert Array into String"
moped (1.0.0.rc) lib/moped/bson/object_id.rb:68:in
__bson_dump__' moped (1.0.0.rc) lib/moped/bson/extensions/hash.rb:37:in
block in bson_dump'moped (1.0.0.rc) lib/moped/bson/extensions/hash.rb:36:in
each' moped (1.0.0.rc) lib/moped/bson/extensions/hash.rb:36:in
bson_dump'moped (1.0.0.rc) lib/moped/bson/document.rb:11:in
serialize' moped (1.0.0.rc) lib/moped/protocol/message.rb:136:in
serialize_selector'moped (1.0.0.rc) lib/moped/protocol/message.rb:296:in
block (2 levels) in serialize' moped (1.0.0.rc) lib/moped/protocol/message.rb:295:in
each'moped (1.0.0.rc) lib/moped/protocol/message.rb:295:in
block in serialize' moped (1.0.0.rc) lib/moped/protocol/message.rb:292:in
tap'moped (1.0.0.rc) lib/moped/protocol/message.rb:292:in
serialize' moped (1.0.0.rc) lib/moped/connection.rb:137:in
block in write'moped (1.0.0.rc) lib/moped/connection.rb:135:in
each' moped (1.0.0.rc) lib/moped/connection.rb:135:in
write'moped (1.0.0.rc) lib/moped/node.rb:489:in
block (2 levels) in flush' moped (1.0.0.rc) lib/moped/node.rb:113:in
ensure_connected'moped (1.0.0.rc) lib/moped/node.rb:488:in
block in flush' moped (1.0.0.rc) lib/moped/node.rb:503:in
logging'moped (1.0.0.rc) lib/moped/node.rb:487:in
flush' moped (1.0.0.rc) lib/moped/node.rb:476:in
process'moped (1.0.0.rc) lib/moped/node.rb:309:in
query' moped (1.0.0.rc) lib/moped/session/context.rb:32:in
block in query'moped (1.0.0.rc) lib/moped/session/context.rb:93:in
block in with_node' moped (1.0.0.rc) lib/moped/cluster.rb:176:in
with_secondary'moped (1.0.0.rc) lib/moped/session/context.rb:92:in
with_node' moped (1.0.0.rc) lib/moped/session/context.rb:31:in
query'moped (1.0.0.rc) lib/moped/query.rb:108:in
first' gems/mongoid/lib/mongoid/contextual/mongo.rb:196:in
first'gems/mongoid/lib/mongoid/contextual.rb:18:in
first' orm_adapter (0.0.7) lib/orm_adapter/adapters/mongoid.rb:32:in
get'devise (2.1.0) lib/devise/models/authenticatable.rb:146:in
serialize_from_session' devise (2.1.0) lib/devise/rails/warden_compat.rb:29:in
deserialize'warden (1.1.1) lib/warden/session_serializer.rb:31:in
fetch' warden (1.1.1) lib/warden/proxy.rb:196:in
user'warden (1.1.1) lib/warden/proxy.rb:293:in
_perform_authentication' warden (1.1.1) lib/warden/proxy.rb:90:in
authenticate'devise (2.1.0) lib/devise/controllers/helpers.rb:56:in
current_user' devise (2.1.0) lib/devise/controllers/helpers.rb:52:in
user_signed_in?'lib/controllers/components.rb:56:in `check_session' # this is : if user_signed_in?
The text was updated successfully, but these errors were encountered: