[Archivesspace_Users_Group] Serving ArchivesSpace with prefix and proxy

Steven D Majewski sdm7g at virginia.edu
Thu Jul 23 22:21:59 EDT 2015



Sent from my iPad

> On Jul 23, 2015, at 10:14 PM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org> wrote:
> 
> Hi Steven,
> 
> Hm. This seems odd...quick sanity check.. Are you using tomcat? 
> 
> 
> b,chris. 
> 
> 

No.


> Chris Fitzpatrick | Developer, ArchivesSpace
> Skype: chrisfitzpat  | Phone: 918.236.6048
> http://archivesspace.org/
> 
> ________________________________________
> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Steven Majewski <sdm7g at virginia.edu>
> Sent: Friday, July 24, 2015 3:11 AM
> To: Archivesspace Users Group
> Subject: Re: [Archivesspace_Users_Group] Serving ArchivesSpace with prefix      and proxy
> 
> There seem to be several different failure modes associated with running with a prefix and proxying thru apache, and it's taken me a while to disentangle them.
> 
> 
> _url settings seem to be mostly used for the launcher and  api links.
> They can contain localhost as a hostname because the apps are all communicating on the same localhost.
> 'localhost' hostname does not get put out on a browser page to another client.
> 
> _prefix are set by default proc, and are used to generate internal links.
> They are just a partial path, not a complete URL.
> 
> _proxy_url is used to produce the links at the bottom of page from frontend to public and back.
> Those links are not generated if _proxy_url matches /localhost/ .
> By default, _proxy_url is the same as _url (which by default matches /localhost/ )
> 
> 
> I set an additional AppConfig for :hostname by proc, so that can deploy the same config
> files I've tested on my laptop, on either test or production servers, without editing.
> Proxy URLs are also set by a proc using AppConfig[:hostname] value.
> 
> When testing on my laptop, I've usually used http://localhost  in the browser URLs.
> But this seems to cause some cross domain AJAX problems:
> 
> [Error] XMLHttpRequest cannot load http://d-172-25-72-74.bootp.virginia.edu/admin/check_session?uri=%2Frepositories%2F5%2Fresources%2F6. Origin http://localhost:8081 is not allowed by Access-Control-Allow-Origin. (6, line 0)
> 
> This error disappears if you use the actual hostname.
> This shouldn't be a problem when deployed on a real server, as you will not be using 'localhost' to connect to non local service.
> Just another gotcha to be aware of when testing.
> 
> Here are the config.rb settings I'm using:
> 
> AppConfig[:hostname] = proc { Socket.gethostname }
> 
> AppConfig[:frontend_url] = "http://localhost:8088/admin" # 8080 used by tomcat!
> AppConfig[:public_url] = "http://localhost:8081/public"
> AppConfig[:frontend_proxy_url] = proc { "http://#{AppConfig[:hostname]}/admin" }
> AppConfig[:public_proxy_url] = proc { "http://#{AppConfig[:hostname]}/public" }
> 
> 
> 
> With that setup, connecting to http://localhost:8088/admin or http://localhost:8081/public will appear to work.
> However, most but not all assets are using the prefix.
> 
> When I try the proxy addres thru apache, with these config settings:
> 
>    ProxyPass /admin     http://localhost:8088/admin
>    ProxyPass /public   http://localhost:8081/public
>    ProxyPassReverse /public http://localhost:8081/public
>    ProxyPassReverse /admin  http://localhost:8088/admin
> 
> I get these missing gylphs on the admin welcome page which results in missing "home" and "gear" icons:
> 
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (bg_body-c33f15fcf9603f5859725ca64c227a48.png, line 0)
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (icomoon.woff, line 0)
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (icomoon.ttf, line 0)
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (icomoon.svg, line 0)
> 
> And this on resource view page:
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (drag_handle-86108b4e00ee63fb682bf9a79c689c03.png, line 0)
> 
> And this on the public pages:
> 
> Public:
> 
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (glyphicons-halflings-b4c22a0ed1f42188864f0046f0862ecb.png, line 0)
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (bg_body-c33f15fcf9603f5859725ca64c227a48.png, line 0)
> 
> ( This is what I've sampled -- there may be more. )
> 
> The URL paths for these assets all start with /assets, not /admin/assets or /public/assets.
> They were served up with those paths when using the non proxied :port URLs, but they are not proxied by the above config.
> 
> 
> 
> Adding a proxy for assets to apache config gets me most of the way there:
>    ProxyPass /assets   http://localhost:8088/assets
> 
> Now the "home" and "gear" icons appear on the admin pages.
> 
> 
> However, I still get some errors from the /public pages since I can only proxy /assets prefix to one of those apps,
> and even if they might use the same assets they may be compiled under a different name:
> 
> [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (glyphicons-halflings-b4c22a0ed1f42188864f0046f0862ecb.png, line 0)
> 
> 
> I had tried this fix of proxying /assets with a different build, however that build was done with my modified config.rb in place in common/config.
> ( I've been using a modified buildfile that adds mysql adapter, local plugins and appends my config.rb to my distribution, so that I can just unzip the distribution and run without requiring any editing or copying of extra files. )
> It turns out that building it that way, the asset paths in the .war files all have the "/public" or "/admin" prefix.
> Building without that config.rb present adds them as "/assets/..." .
> 
> 
> A clue: The assets that are not getting prefixed correctly all seem to be coming from twitter bootstrap.
> 
> Now that I have separated some of the issues, I may revist the issues with my custom build.
> I'm not sure if those different pathnames in the webapp were a problem or not, as I also had things mostly working under that scheme as well.
> If it is a problem, I will probably have to keep my custom config around under another name to prevent it from being loaded in the build process, but to still append that file to the generated config.rb .
> 
> 
> There is still the issue of LCNAF plugin paths being broken. I haven't looked at that issue yet.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



More information about the Archivesspace_Users_Group mailing list