Hmm, in the case of the bug report it was a 64 bit val being truncated
to a 32bit val.
I'll change things around and test if it's an int (even though
truncated it'll still be an int), but if it is, return the original
unadjusted value.
Thanks for catching that Brian!
-- Chris
On Aug 22, 2008, at 9:49 PM, Brian Eaton wrote:
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.
