Solr
  1. Solr
  2. SOLR-1894

Solr Itas sample app does not work on multicore

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: Response Writers
    • Labels:
      None

      Description

      The SolrItas sample app does not support multicore - it hard-codes the Solr URL to the default.
      [comment about security removed - this issue is solely about fixing Itas to work natively on multicore]

        Activity

        Hide
        Erik Hatcher added a comment -

        How is use of /admin/file a security hole? Solr's admin uses it for serving up schema.xml and solrconfig.xml, for example.

        As for multicore, indeed the URLs linked in the example are specific to the way it is deployed. I'm all ears to hearing how it should be done better and more generically. Maybe entirely relative URLs, I suppose, would be the way to go?

        Show
        Erik Hatcher added a comment - How is use of /admin/file a security hole? Solr's admin uses it for serving up schema.xml and solrconfig.xml, for example. As for multicore, indeed the URLs linked in the example are specific to the way it is deployed. I'm all ears to hearing how it should be done better and more generically. Maybe entirely relative URLs, I suppose, would be the way to go?
        Hide
        Lance Norskog added a comment -

        /admin/file can fetch a DataImportHandler file which has login credentials somewhere...
        Solr has tons of security holes.

        I changed '/solr/itas' to just 'itas' in browse.vm and VM_global_library.vm. .
        (Also, the example in the wiki page had the file type as text/xml and it should be text/html. I just fixed that.)
        Now it works in a multicore setup.

        This was in the trunk, I don't know what happens in Solr 1.4. Nor have I tried it on the default core.

        Cheers!

        Show
        Lance Norskog added a comment - /admin/file can fetch a DataImportHandler file which has login credentials somewhere... Solr has tons of security holes. I changed '/solr/itas' to just 'itas' in browse.vm and VM_global_library.vm. . (Also, the example in the wiki page had the file type as text/xml and it should be text/html. I just fixed that.) Now it works in a multicore setup. This was in the trunk, I don't know what happens in Solr 1.4. Nor have I tried it on the default core. Cheers!
        Hide
        Eric Pugh added a comment -

        I made full paths by adding in the core name which is in the request:

        #macro(url_for_home)
        /solr/$request.core.name/itas
        #end

        Show
        Eric Pugh added a comment - I made full paths by adding in the core name which is in the request: #macro(url_for_home) /solr/$request.core.name/itas #end
        Hide
        Erik Hatcher added a comment -

        Let's take security out of this issue though, Lance. The ShowFileRequestHandler has a facility to hide files, and the data import handler configuration can use system/JNDI properties for usernames/passwords - so that mischief is managed for those that wanna lock it down further, beyond simply blocking outside ports from hitting Solr, only application servers.

        But again, security isn't part of this issue of making Solritas robust enough out of the box for multicore paths.

        Thanks, Eric for that general purpose example.

        Show
        Erik Hatcher added a comment - Let's take security out of this issue though, Lance. The ShowFileRequestHandler has a facility to hide files, and the data import handler configuration can use system/JNDI properties for usernames/passwords - so that mischief is managed for those that wanna lock it down further, beyond simply blocking outside ports from hitting Solr, only application servers. But again, security isn't part of this issue of making Solritas robust enough out of the box for multicore paths. Thanks, Eric for that general purpose example.
        Hide
        Erik Hatcher added a comment -

        Using the core name dynamically, the example Solritas templates now are automatically multicore savvy. I tested this by copying the example single core config to a new core under example/multicore, adjusting solr.xml for a new core, and trying the /browse handler. All worked as expected with no template changes at all.

        Show
        Erik Hatcher added a comment - Using the core name dynamically, the example Solritas templates now are automatically multicore savvy. I tested this by copying the example single core config to a new core under example/multicore, adjusting solr.xml for a new core, and trying the /browse handler. All worked as expected with no template changes at all.
        Hide
        Robert Muir added a comment -

        I think it makes sense to merge this bugfix to 3.x also. will put a combined merge patch on SOLR-1957

        Show
        Robert Muir added a comment - I think it makes sense to merge this bugfix to 3.x also. will put a combined merge patch on SOLR-1957
        Hide
        Robert Muir added a comment -

        merged to 3x (revision: r964820)

        Show
        Robert Muir added a comment - merged to 3x (revision: r964820)
        Hide
        Grant Ingersoll added a comment -

        Bulk close for 3.1.0 release

        Show
        Grant Ingersoll added a comment - Bulk close for 3.1.0 release

          People

          • Assignee:
            Robert Muir
            Reporter:
            Lance Norskog
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development