It seems google cloud storage provides a different behavior whether a folder is access from a web client with or without a trailing /
A simple test shows a different behavior for the following link
http://gstest.tekartik.com/sub/dir (fail to load css - background is white)
http://gstest.tekartik.com/sub/dir/ (works ok - background is black)
Where the bucket has been configured using:
gsutil setwebcfg -m index.html -e 404.html gs://gstest.tekartik.com
For information it contains 3 simple files index.html/404.html/style.css where style.css only set the background to black.
They both correctly "redirect" to the url http://gstest.tekartik.com/sub/dir/index.html. However the relative path does not allow for style.css to be loaded properly in the first case.
What I would like is to have the 1st case to be redirected using a trailing / (which is what Amazon S3 does). What is needed for this to work propertly so that I can give a url to someone without worrying about whether the trailing / is entered?
as a side, this works fine as at the root level (http://gstest.tekartik.com/ got automatically renamed to http://gstest.tekartik.com as here the trailing / is not needed)
I've spoken with the engineering team and we agree this should work the way you expected. This will be fixed in the near term by adding a bucket configuration setting to enable the expected behavior (the extra config step is needed to avoid breaking any apps depending on the current behavior). We're also planning to make it easy to update the new config setting via gsutil. I can't say when exactly these changes will be available but tune into the gs-announce group to monitor these (and other) details about Google Cloud Storage. Thanks for bringing this to our attention.
Update (June 3, 2013): This has now been fixed in production.
Related
I'd like to configure the Adobe Cloud Manager production pipeline to invalidate the whole dispatcher cache. What paths do I have to give at the production pipeline dispatcher invalidation configuration to have that done? Is it possible to give a pattern here that matches everything? The page-invalidate description talks about a path-pattern, but doesn't describe what exactly that means.
We work with statfilelevel=2. It seems the .stat files are very important for that, though the description given here is unfortunately not precise enough, not sure I understand that right.
I tried to configure /content as path - that just touches /mnt/var/www/html/.stat (/mnt/var/www/html is the docroot), which seems to apply to nodes like /* but not like /content/* .
If I give /content/oursite, that touches /mnt/var/www/html/content/.stat , too, but that does seem to apply to nodes like /content/oursite or /content/othersite, but not to pages like /content/oursite/about - for which would /mnt/var/www/html/content/oursite/.stat be relevant, if I understand that right.
Do I seriously have to enumerate a page in each site that has a .stat file, or is there a more sensible way to get everything invalidated? After all, a deployment could easily change the HTML of every page if a component has changed.
If you have ACS commons installed then you can try to use this powerful feature
https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html
I have a django instance set up on pythonanywhere.
I have debug turned off in my settings
I have a STATIC_ROOT setting of os.path.join(BASE_DIR, "allstatic").
I have set up the static files mapping in the Web section of my pythonanywhere console
URL = /allstatic/
Directory = /home/username/project/allstatic
(I'm calling it allstatic so I can tell that the files are coming from the mapping)
I have run collectstatic and /allstatic has files in it.
I am using {% static 'folder/file' %} in my templates
And with all this - the static files were all being delivered. However, when I checked the page source HTML, they all appeared to be coming from '/static' So I wasn't sure if they were being delivered by the more efficient console driven mapping.
When I changed 'STATIC_URL' setting to 'allstatic' the html shows '/allstatic' and the files still load. BUt I'm not sure how to tell if my mapping is working.
To use a concrete example
I have an app called 'universal' in django, with the following structure
universal
static
universal
img
logo.png
In my local dev environment, with debugging on, this shows up as /static/universal/img/logo.png
However, in my prod environment with debugging off and all the above steps taken, this also shows up as /static/universal/img/logo.png - until I set the STATIC_URL to allstatic
How can I be sure I am using the allstatic mapping I set in the pythonanywhere console? And does STATIC_URL affect whether I am using it or not?
I figured it out.
In order to test that the web console static mapping is working on pythonanywhere, I made the following setting explicit and then commented out AppDirectoriesFinder
STATICFILES_FINDERS = [
'django.contrib.staticfiles.finders.FileSystemFinder',
#'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]
This ensures that app directories aren't being looked at to find static files - it will require the Web Console page mapping (or an entry in STATICFILES_DIRS which is empty by default) to be set up correctly to find files.
Doing this I was able to find that my previous STATIC_URL setting of 'static/' rather than 'allstatic/' had in fact been failing to use the mapping - something previously obscured by the fact that both /static/universal/img/logo.png and /allstatic/universal/img/logo.png seemed to work.
(It's interesting that the app level /static locations still work on pythonanywhere with debug turned off - I suspect this fact was muddling me a bit).
Halp! I am writing an internal macOS app for our IT staff to perform some org-specific tasks, and am also adding some shortcuts for simple, but common tasks that they do. One of those tasks is to rename a user when migrating between domains. This app has a Privileged Helper available (via SMjobBless) to perform most of the tasks. However, it appears that this helper tool, despite its privileged execution context, is unable to rename a user's home directory.
My first attempt at implementing this specific task in the helper was to run a short shell script via Process() (a technique used successfully for dozens of other tasks in this helper).
let script = """
set -e
mv '\(homeDirPath)' /Users/\(toUsername)
dscl . -change /Users/\(fromUsername) NFSHomeDirectory '\(homeDirPath)' '/Users/\(toUsername)'
dscl . -change /Users/\(fromUsername) RecordName \(fromUsername) \(toUsername)
"""
I get the following output on stderr (/Users/newname verified to not exist):
mv: rename /Users/oldname to /Users/newname: Operation not permitted
Trying this as a non-root user gives a different error: mv: rename /Users/oldname to /Users/newname: Permission denied
Okay, weird. Add whoami to the top of the script to double check the user context: root. Well... interesting. Wth, I can do this just fine via sudo in my user session.
Then I try using FileManager thinking there might be some SIP interference or sandboxing for child processes of a launchdaemon (despite not finding any docs that say this), but I still get an error - but more verbose this time:
Error: “oldname” couldn’t be moved because you don’t have permission to access “Users”.
I've tried searching for documentation for whatever restriction I am up against, but I'm at a loss. The directory doesn't appear to be under SIP's protection, and I can't find any docs for daemon sandboxing outside of the app store (the parent app does not have the App Sandbox capability enabled). Can anyone point me in the right direction?
Update: It doesn't appear to be affected by 10.14's Privacy Protection. Adding the helper to "Full Disk Access" doesn't resolve. Perhaps I am adding the helper incorrectly: had to change the build target to 10.14 (which will be a problem), then dragged the helper binary from within the App bundle into the list. I cannot add it from /Library/PrivilegedHelperTools/ - it is greyed out as an option to add.
Update 2: Correction, it does appear to be FDA related. iTerm was in the FDA list. Removing it causes it to throw Operation not permitted, then adding it back resolves. So I'm now chasing down how to properly add the helper to the FDA list.
Okay, it's confirmed - Mojave's Privacy Protections apply even to privileged tools. The solution was to make the helper binary executable by all so it can be allowed to be added to the Full Disk Access table.
Hopefully, this helps someone in the future who is initially puzzled by what they're seeing.
Here's to hoping that Apple adds a standardized, easier method for the user to grant this access to helpers.
We have been using the following library for months:
https://unpkg.com/react#15.3.0/dist/react.min.js
Yes - I know we can just reference 15.3 and get the URL rewrite to the latest, but they released a breaking change. That's another issue for another day. Don't get distracted.
Yesterday this simply stopped working. You'll notice that if you load the URL mentioned, that the file is TRUNCATED. Simply cuts off. This made everything we use react with break. Interestingly, if you go to the following URL (without the .js extension) - things work.
https://unpkg.com/react#15.3.0/dist/react.min
My question is - what the heck happened? Why did the URL we've been using for 8 months suddenly stop working, and who can we get to fix it. In the interim, we had a copy locally that we've started referencing (which we probably should have been doing to begin with, since we don't want the automatic upgrade). When things like this happen, who do you inform?
I'm not sure you'll find the answer as to why this file is no longer working here but based off of the website you could reached out to the creator on twitter: https://twitter.com/mjackson
On the website it says:
SUPPORT
unpkg is a free, best-effort service and cannot provide any uptime or
support guarantees.
i.e. you should probably only use this link if you are messing around with a small project and shouldn't be used for any website where you actually care about the uptime of the site.
Following the steps mentioned at mybatis-ignite integration page # mybatis-ignite with Ignite 2.0, i see that the call to the mapper hangs & never returns. This is after working around several other issues like requiring ignite-cache configuration to be placed in IGNITE_HOME/config/default-config.xml which still doesn't get picked up unless i place it in a physical location in the project dir (otherwise i see the error in the log "Initializing the default cache. Consider properly configuring 'config/default-config.xml' instead.") which again also seems to have no effect.
Since the integration seems to have several issues i am not sure if it is still supported..any thoughts from any one who has successfully done this or from the mybatis-ignite team would be great.
Edit: If it helps, i have placed a small self contained project # https://github.com/softwarebrahma/MyBatis-Ignite-L2-cache-POC that can be used to reproduce the issues i have mentioned.
I missed mentioning in the repo..but only the Ports table & schema is used for the purposes of the demo the other tables are not used. What happens is that in the file (github.com/softwarebrahma/MyBatis-Ignite-L2-cache-POC/blob/master/domain/src/main/java/com/brocade/dcm/domain/xml/PostsMapper.xml) if i remove the line "cache type="org.mybatis.caches.ignite.IgniteCacheAdapter" />" then everything will work fine without ignite caching. But the moment i add that line as shown in the uploaded file the mapper method calls just hangs.