" Working hours must include US Central Time morning time (8am-12pm CT).
这里的 12pm 代表的是中午 12 点吧。如果是这样的话,也就是说对应中国的晚上 10 点 - 凌晨 2 点。
期望尽快支持远程
嗯嗯,是的,每个人会不一样,所以找到适合自己的就是最好的
一样的,我一开会我女儿就要凑过来看,很想上镜,还想学电脑,不过我更想她学跳舞
哈哈,当然可以,已经添加,期待沟通:)
更新的时候附件会失效的问题已经找到原因,这个是 Rails 自身的一个 bug,当我们使用rich_text_area_tag
的时候就会有这个问题,如果你使用的是rich_text_area
就不会有这个问题。参考:
https://github.com/rails/rails/issues/37405
赞同,不过不是必须啦,有最好
没有搞不定的需求,只是看需要花多大的时间和精力去搞定
这个确实,对每个人而言是不一样的。所以,如何利用好处,规避坏处,就看个人了。
结果导向。只要大家能接受,有效果,方法可以不断变化和改进嘛。
嗯嗯,那多沟通交流:)
以为是 12 生肖,数一下发现多了三个
嗯呢,这就是社区的力量啊,非常喜欢 Ruby 社区。
https/http 同源的问题解决了。还有两个问题我需要继续探索,到时候解决了,我会把方案都贴过来。
👍,查验了,https 的问题,确实是这个原因。之前的配置是:
location / {
proxy_pass "http://myapps";
proxy_set_header X-Forwarded-Host blog-staging.com;
proxy_redirect default;
}
改成了这个就好啦:
location / {
proxy_pass "http://myapps";
proxy_set_header X-Forwarded-Host blog-staging.com;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect default;
}
是的,大概率是这样,不过集成环境的不同,可能会遇到不一样的问题,这也是分享的意义。
嗯嗯,谢谢啦,很好的建议。我下来再研究下。
这里配置的是 Aliyun OSS 的 endpoint,上面提到的 https/http 的错误其实还没到使用这个配置。报错的域名地址还是本地:
假设我们 test 的地址是: https://blog-test.com
那么错误信息是这样的:
The page at 'https://blog-test.com/blogs/new' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://blog-test.com/rails/active_storage/direct_uploads'. This request has been blocked, the content must be served over HTTPS.
是我表述不严谨,我说的 staging 其实就是 test 环境。只是我习惯把它叫做 staging 了。已经在文中修正了。
@teddyinfi @lidashuang @flyweights @spike76 谢谢回复,我在文中贴了配置了。我使用了阿里云 OSS 的,而且独立使用 ActiveStorage 是没有问题的。所以应该不是各位说的 volume 或者 Disk 使用的问题。
这个我不太确定了,需要探索下。不过如果没有持久化的话,那在新建之后在 show 页面渲染的时候应该就会出问题,只是我的猜测 。
我贴了下配置在文章中,本地和 test 环境都是用了 aliyun oss 的。
嗯嗯,是的。不过我这里的情况是,precompile 在 Dockerfile,需要提交到代码库。所以 GitLab 的环境变量用不上,master key 又不能放代码库。所以才有了这个问题。
这个还没有研究过 ,到时候实践了再回来补充
这个环境变量可以工作的,只是这里因为是在 Dockerfile 里面,所以不想暴露 master key。
这个可以,设置为 false 之后,需要的就只有 SECRET_KEY_BASE,然后就可以用第一条评论的方法了。
RAILS_ENV=production rails assets:precompile
rails aborted!
ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `bin/rails credentials:edit`
可能你理解错了,这个环境变量没问题。这里是说利用 CI build 的时候,我们怎么避免 master key 暴露在 code 中。
嗯嗯,在我参考的那个帖子里面也人提到您的这个方案。如果按照“代码和配置严格分离”,确实把所有这些都放到环境变量是最安全的。不过我不太确定 Rails 'credentials.yml', 从安全性的角度来讲,会有风险吗?或者说在没有 master.key 的情况下,想要获取里面的内容难度有多大?
是的
顶一个! 本人亲测以上描述没有水分,是一个值得托付的好公司!
我出来挺久了,但是很喜欢活跃。 里面做 Ruby 的人现在应该不多,之前很多。