Opened 16 years ago
Closed 20 months ago
#10327 closed Cleanup/optimization (wontfix)
Pass document.domain to popup windows in admin
| Reported by: | Joost Cassee | Owned by: | nobody |
|---|---|---|---|
| Component: | contrib.admin | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
Some applications require Javascript collaboration between views and scripts from the static media location. When these are served from different domains collaboration fails because of the same origin policy implemented in browsers. Scripts can still work together if they are served from subdomains with a common parent (for example, www.example.com and media.example.com) by setting the document.domain variable to that common parent (in the example, example.com).
Unfortunately, the document.domain variable is not automatically passed to newly opened windows. The attached patch passes the variable to popup windows in the admin interface. Currently it is always passed, but may be nicer to do so only if it is different from the real server name. There are also currently no tests; I'm unsure how to test this functionality.
The patch was tested with the TinyMCE editor, which uses the above trick for its own popup windows. The patch allows, for example, the raw_id_fields functionality to work again for pages with TinyMCE editors (when static files are served from a different domain).
Attachments (2)
Change History (14)
by , 16 years ago
| Attachment: | 10327-r9845.diff added |
|---|
comment:1 by , 16 years ago
| milestone: | → 1.1 |
|---|---|
| Patch needs improvement: | set |
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 16 years ago
by , 16 years ago
| Attachment: | 10327-r9969.diff added |
|---|
comment:3 by , 16 years ago
| Has patch: | set |
|---|---|
| Patch needs improvement: | unset |
Setting has_patch and removing needs_better_patch to invite patch review.
comment:4 by , 16 years ago
| milestone: | 1.1 → 1.2 |
|---|
Pushing to 1.2 since this is an uncommon case. For now you can use a custom template along with the custom widget to do this same thing if you need.
follow-up: 6 comment:5 by , 15 years ago
| Patch needs improvement: | set |
|---|
Patches proposed breaks the Admin ForingnKey javascript (/media/js/admin/RelatedObjectLookups.js)
I have changed my prospectives, all static resources affected by this bug, for the "Same origin policy", will be served by central site.
comment:6 by , 15 years ago
Replying to s.federici:
Patches proposed breaks the Admin ForingnKey javascript (/media/js/admin/RelatedObjectLookups.js)
Funny, the patch was supposed to fix the admin ForeignKey problem. I'll look into it, thanks for the heads-up.
I have changed my prospectives, all static resources affected by this bug, for the "Same origin policy", will be served by central site.
Sorry, I don't really understand this sentence.
comment:7 by , 15 years ago
| milestone: | 1.2 |
|---|
1.2 is feature-frozen, moving this feature request off the milestone.
comment:8 by , 14 years ago
| Severity: | → Normal |
|---|---|
| Type: | → Bug |
comment:12 by , 20 months ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
| Type: | Bug → Cleanup/optimization |
The document.domain setter is deprecated and dangerous.
The new patch only appends the
jsdomquery parameter if the Javascript domain differs from the location domain. Additionally, it is given its own variable in the template context (likeis_popup). I hope the patch is now good enough to be applied, otherwise please indicate how to improve it.