Skip to content
This repository has been archived by the owner on Jan 15, 2024. It is now read-only.

Error with Devise devise-2.1.0 #21

Closed
jackbit opened this issue Jun 10, 2012 · 22 comments
Closed

Error with Devise devise-2.1.0 #21

jackbit opened this issue Jun 10, 2012 · 22 comments
Assignees
Milestone

Comments

@jackbit
Copy link

jackbit commented Jun 10, 2012

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:inblock 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:inbson_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:inserialize_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:ineach'
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:intap'
moped (1.0.0.rc) lib/moped/protocol/message.rb:292:in serialize' moped (1.0.0.rc) lib/moped/connection.rb:137:inblock in write'
moped (1.0.0.rc) lib/moped/connection.rb:135:in each' moped (1.0.0.rc) lib/moped/connection.rb:135:inwrite'
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:inensure_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:inlogging'
moped (1.0.0.rc) lib/moped/node.rb:487:in flush' moped (1.0.0.rc) lib/moped/node.rb:476:inprocess'
moped (1.0.0.rc) lib/moped/node.rb:309:in query' moped (1.0.0.rc) lib/moped/session/context.rb:32:inblock 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:inwith_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:inquery'
moped (1.0.0.rc) lib/moped/query.rb:108:in first' gems/mongoid/lib/mongoid/contextual/mongo.rb:196:infirst'
gems/mongoid/lib/mongoid/contextual.rb:18:in first' orm_adapter (0.0.7) lib/orm_adapter/adapters/mongoid.rb:32:inget'
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:indeserialize'
warden (1.1.1) lib/warden/session_serializer.rb:31:in fetch' warden (1.1.1) lib/warden/proxy.rb:196:inuser'
warden (1.1.1) lib/warden/proxy.rb:293:in _perform_authentication' warden (1.1.1) lib/warden/proxy.rb:90:inauthenticate'
devise (2.1.0) lib/devise/controllers/helpers.rb:56:in current_user' devise (2.1.0) lib/devise/controllers/helpers.rb:52:inuser_signed_in?'
lib/controllers/components.rb:56:in `check_session' # this is : if user_signed_in?

@durran
Copy link
Member

durran commented Jun 10, 2012

Does devise store the ids in the session without converting them to strings by chance?

@jackbit
Copy link
Author

jackbit commented Jun 10, 2012

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
but i put like this in object_id.rb to remove the error:
def data
@ data = nil if @ data.is_a?(Array)
@ data ||= @@generator.next
end

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.

@durran
Copy link
Member

durran commented Jun 10, 2012

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.

@jackbit
Copy link
Author

jackbit commented Jun 10, 2012

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.

@jackbit jackbit closed this as completed Jun 10, 2012
@durran
Copy link
Member

durran commented Jun 10, 2012

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.

@JamesHarrison
Copy link

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.

@jackbit
Copy link
Author

jackbit commented Jun 12, 2012

@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.

@durran durran reopened this Jun 12, 2012
@ghost ghost assigned durran Jun 16, 2012
adamtrilling added a commit to adamtrilling/moped that referenced this issue Jun 16, 2012
@jonhyman
Copy link
Contributor

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.

ActionDispatch::Session::SessionRestoreError (Session contains objects whose class definition isn't available. Remember to require the classes for all objects kept in the session. (Original exception: uninitialized constant Moped [NameError]) ): actionpack (3.2.3) lib/action_dispatch/middleware/session/abstract_store.rb:62:in rescue in rescue in stale_session_check!' actionpack (3.2.3) lib/action_dispatch/middleware/session/abstract_store.rb:58:inrescue in stale_session_check!' actionpack (3.2.3) lib/action_dispatch/middleware/session/abstract_store.rb:55:in stale_session_check!' actionpack (3.2.3) lib/action_dispatch/middleware/session/cookie_store.rb:51:inunpacked_cookie_data' rack (1.4.1) lib/rack/session/cookie.rb:98:in extract_session_id' actionpack (3.2.3) lib/action_dispatch/middleware/session/abstract_store.rb:51:inblock in extract_session_id' actionpack (
Jun 19 10:29:27 ip-10-194-238-239 myapp_staging[9573]: [10:29:27.242084000] 3.2.3) lib/action_dispatch/middleware/session/abstract_store.rb:55:in stale_session_check!' actionpack (3.2.3) lib/action_dispatch/middleware/session/abstract_store.rb:51:inextract_session_id' rack (1.4.1) lib/rack/session/abstract/id.rb:43:in load_session_id!' rack (1.4.1) lib/rack/session/abstract/id.rb:32:in[]' rack (1.4.1) lib/rack/session/abstract/id.rb:262:in current_session_id' rack (1.4.1) lib/rack/session/abstract/id.rb:268:insession_exists?' rack (1.4.1) lib/rack/session/abstract/id.rb:107:in exists?' rack (1.4.1) lib/rack/session/abstract/id.rb:122:inload_for_read!' rack (1.4.1) lib/rack/session/abstract/id.rb:64:in has_key?' actionpack (3.2.3) lib/action_dispatch/middleware/flash.rb:258:inensure in call' actionpack (3.2.3) lib/action_dispatch/middleware/flash.rb:259:in call' rack (1.4.1) lib/rack/session/abstract/id.rb:205:incontext'
Jun 19 10:29:27 ip-10-194-238-239 myapp_staging[9573]: [10:29:27.242143000] rack (1.4.1) lib/rack/session/abstract/id.rb:200:in call' actionpack (3.2.3) lib/action_dispatch/middleware/cookies.rb:338:incall' actionpack (3.2.3) lib/action_dispatch/middleware/callbacks.rb:28:in block in call' activesupport (3.2.3) lib/active_support/callbacks.rb:405:in_run__139213512__call__422077887__callbacks' activesupport (3.2.3) lib/active_support/callbacks.rb:405:in __run_callback' activesupport (3.2.3) lib/active_support/callbacks.rb:385:in_run_call_callbacks' activesupport (3.2.3) lib/active_support/callbacks.rb:81:in run_callbacks' actionpack (3.2.3) lib/action_dispatch/middleware/callbacks.rb:27:incall' actionpack (3.2.3) lib/action_dispatch/middleware/remote_ip.rb:31:in call' actionpack (3.2.3) lib/action_dispatch/middleware/debug_exceptions.rb:16:incall' actionpack (3.2.3) lib/action_dispatch/middleware/show_exceptions.rb:56:in call' Jun 19 10:29:27 ip-10-194-238-239 myapp_staging[9573]: [10:29:27.242250000] railties (3.2.3) lib/rails/rack/logger.rb:26:incall_app' railties (3.2.3) lib/rails/rack/logger.rb:16:in call' actionpack (3.2.3) lib/action_dispatch/middleware/request_id.rb:22:incall' rack (1.4.1) lib/rack/methodoverride.rb:21:in call' rack (1.4.1) lib/rack/runtime.rb:17:incall' activesupport (3.2.3) lib/active_support/cache/strategy/local_cache.rb:72:in call' rack (1.4.1) lib/rack/lock.rb:15:incall' actionpack (3.2.3) lib/action_dispatch/middleware/static.rb:62:in call' rack-cache (1.2) lib/rack/cache/context.rb:136:inforward' rack-cache (1.2) lib/rack/cache/context.rb:245:in fetch' rack-cache (1.2) lib/rack/cache/context.rb:185:inlookup' rack-cache (1.2) lib/rack/cache/context.rb:66:in call!' rack-cache (1.2) lib/rack/cache/context.rb:51:incall' railties (3.2.3) lib/rails/engine.rb:479:in call' railties (3.2.3) lib/rails/application. Jun 19 10:29:27 ip-10-194-238-239 myapp_staging[9573]: [10:29:27.242307000] rb:220:incall' railties (3.2.3) lib/rails/railtie/configurable.rb:30:in method_missing' rack (1.4.1) lib/rack/urlmap.rb:64:inblock in call' rack (1.4.1) lib/rack/urlmap.rb:49:in each' rack (1.4.1) lib/rack/urlmap.rb:49:incall' rack (1.4.1) lib/rack/deflater.rb:13:in call' unicorn (4.3.1) lib/unicorn/http_server.rb:531:inprocess_client' unicorn (4.3.1) lib/unicorn/ht

bernerdschaefer added a commit that referenced this issue Jun 22, 2012
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]
@bernerdschaefer
Copy link
Contributor

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.

@tobowers
Copy link

tobowers commented Aug 7, 2012

Hmmm... I'm seeing a similar problem, but not exactly that:

undefined method `__bson_dump__' for BSON::ObjectId('50207699c7e47811ab000017'):BSON::ObjectId

Happens because warden in mongoid2 was storing the BSON::ObjectId('...') but then when you upgrade to mongoid3 you no longer have that object.

@durran
Copy link
Member

durran commented Aug 7, 2012

@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?

@tobowers
Copy link

tobowers commented Aug 7, 2012

@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.

@ahoward
Copy link
Contributor

ahoward commented Aug 7, 2012

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
in the application, can you try doing:

BSON = Moped::BSON

somewhere in your app and see if that helps?


Reply to this email directly or view it on
GitHubhttps://github.com//issues/21#issuecomment-7564081.

@durran
Copy link
Member

durran commented Aug 7, 2012

@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.

@ahoward
Copy link
Contributor

ahoward commented Aug 7, 2012

@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

@ahoward
Copy link
Contributor

ahoward commented Aug 7, 2012

@tobowers perhaps monkey-patch with an appropriate def of 'bson_dump' somewhere...

@callumj
Copy link

callumj commented Nov 30, 2012

@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

@alduro
Copy link

alduro commented Feb 14, 2013

were there any workaround for this issue ? I'm having it in the middle of a migration to monogid 3.x in production now.

@callumj
Copy link

callumj commented Feb 15, 2013

@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.

@alduro
Copy link

alduro commented Feb 15, 2013

@callumj Thanks ! Where did you put your solution ? under lib/bson/object_id.rb ?

@callumj
Copy link

callumj commented Feb 15, 2013

@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

@alduro
Copy link

alduro commented Feb 15, 2013

@callumj got it Thanks !

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants