There's a disconnect between java and PHP here, the java security token forces the module ID to be an int. The gadget id can be a string.
Intended usage: - gadget ID: an opaque identifier for the gadget, i.e. 123456 - gadget URL: a useful identifier for the gadget, preferred over the gadget ID. - module ID: used to distinguish between different instances of the same gadget installed by the same user. Is the disconnect at the semantic level, or just between whether we have 32 bit or 64 bit values? On Fri, Aug 22, 2008 at 12:26 PM, Chris Chabot (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SHINDIG-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Chris Chabot resolved SHINDIG-531. > ---------------------------------- > > Resolution: Fixed > Assignee: Chris Chabot > > Good catch, that made no sense that the intval() was there, fix committed. > Thanks! > >> Support arbitrary module id in BasicSecurityToken >> ------------------------------------------------- >> >> Key: SHINDIG-531 >> URL: https://issues.apache.org/jira/browse/SHINDIG-531 >> Project: Shindig >> Issue Type: Improvement >> Components: Common Components (PHP) >> Reporter: Artemy Tregubenko >> Assignee: Chris Chabot >> Priority: Trivial >> Attachments: arbitrary_module_id.diff >> >> Original Estimate: 0.08h >> Remaining Estimate: 0.08h >> >> Method BasicSecurityToken#getModuleId uses intval() to coerce module id to >> integer before returning. However these id can be arbitrary in some systems. >> In my case, these are bigints, and are truncated to 2^32 by intval. This >> onle-line patch removes coercion. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
