  |
はてなキーワード: ZOHOとは
きっかけはLightiningに上げようと色々調べてみたこと。
立ち上げる度にLightingの画面に切り替わって催促されるしｗ。
その中でこれはキツいな、受け入れられないな、と感じたのが下の2つ。
その1 差し込み印刷が出来ない。
Salesforceに限らず古いバージョンで出来てたことが出来なくなるのは
仕方ないのでテストも兼ねて弊社のプログラマーに頼んで作らせてみた。
DBの中身拾ってきてhtmlで整形する、という手法でやってみた。まあ出来るようにはなった。
なんだけどこの程度のことでわざわざプログラマーの手を煩わして
コーディングってのもちと違うよね。簡単に出来ることに手間かけるってのは本末転倒の極み。
おまけにAPI使うには追加費用が必要云々言ってきた。まあそういう価格体系なんだろうけどそもそも使ってた機能が
使えなくなったことが要因なのでこれには不満が残った。
お客様のライセンスでは開発のサポートは出来ません、みたいな連絡も頂いた。
これも正しいんだろうけど、たかが差し込み印刷を開発というのもどうなのかと？
簡単なことをわざわざ「開発」しないと出来ないことがむしろ問題なので。
日本人って帳票沢山使う民族なのでこれ出来なくて困ってる人沢山いるんじゃないかな。
プラグイン作ってるとこは儲かるかもしれないが。
が、なんと現行のナレッジベースとLightingの互換性がないらしい。
サポートに聞いてみると自分でローダー使って移してくださいと。出来ない場合は手で入力してくださいと。
何百件あるのを手で入力って言うのは簡単だけど現実的ではないよね。
が、そもそも同じソフト/サービスで新バージョンに移行するにあたって
あとそもそもローカルでそういう面倒なことやんなくていいのがクラウドのメリットだったはず。
データ自分で移行しなきゃいけないなら他のシステムにいくのと変わらないと、判断し
この時点で決心した。
それと今のライセンス(Professional)ではLightingに上げるとそもそもナレッジベース使えないらしい。
つまり新しいほういくとライセンスを上のグレードに上げる必要がある。
つまり、実質的な値上げなんだけど、どこにも値上げと唄ってない。
こういうやり方、手法を取ったとしたらそれはベンダー側の判断。こっちが決めることじゃないので。
が、いかにも後味悪い。遺恨を残す。なんだかなあと。
何故か怒りは全く湧いてこず一番良い手法を
早く見つけようという気になった。SFのサポートや営業を責めても仕方ないしね。
彼らは彼らの仕事を真面目にやってるだけなんで。実際一生懸命やってくれたし。
で、ZOHOのデモ版登録して色々試してみた。他のも色々見てみたけど
移行が簡単そうだったので。
途中引っかかる点もあったがサポートの力を借りながら全部のデータ無事に移行終了。
こちらで運用開始、そして今に至ってる。弊社はあんまり難しいことやってないからね。
カスタムオブジェクトがいくつかあるぐらい。あとはサブスクリプションの管理の項目がなかったので
予め作っておいた。
UIはそう言われても仕方ないと思う）、だったので中身よく似てる。
直ぐに使えるようになった。ぶっちゃけUIはこっちのほうが良いんじゃないかな。
あとコストの点も大きい。
SFはずっと1人会社の頃から使ってて、会社が大きくなって人数増えてもユーザーは小生一人だけだった。
が、この先新規事業でユーザー増えてくのでその前に移っておいてホント良かったかなと。
10年以上使ってたシステムを移行するの躊躇した時もあったがやってみると
思いの外簡単だった。色々弄ってると今は使ってないテンプレートとか
出てきてああ、こんなことやってたなあと、感慨深かった。
色々あったがSaleforceにはここで改めて礼を言っておこう。
SF/CRM的なサービス今は沢山あるので自分にあったのを選べば良いと思う。
Tampermonkey
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ja
https://addons.mozilla.org/de/firefox/addon/greasemonkey/
// ==UserScript==
// @name unvisualizer
// @namespace http://anond.hatelabo.jp/
// @description unvisualize section including specific word at Hatelabo::AnonymousDiary
// @include http://anond.hatelabo.jp/*
// @exclude http://anond.hatelabo.jp/hatena/*
// ==/UserScript==
(function() {
var target = document.evaluate(
"//div[@class='section' and descendant::*[contains(text(),'Troyes') or contains(text(),'fiorentina') or contains(text(),'genoa') or contains(text(),'forums.zoho') or contains(text(),'medhelp.zendesk') or contains(text(),'.co.uk/') or contains(text(),'elbertcountyrepublicans') or contains(text(),'purob.com') or contains(text(),'imvu.com') or contains(text(),'thelittleonescollection') or contains(text(),'nfyi.org') or contains(text(),'usa-fox-tv.kinja.com') or contains(text(),'livestream1.odiblogs.com') or contains(text(),'reddit.com') or contains(text(),'huffduffer.com') or contains(text(),'healthunlocked.com')or contains(text(),'surveymonkey.com')or contains(text(),'yakmari.kinja.com')or contains(text(),'putlockeronline') or contains(text(),'freefullmovies.website') or contains(text(),'change.org')or contains(text(),'nervefullmovie.com') or contains(text(),'navtv.co.za')or contains(text(),'Hrvatska')]]",
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);
for(var i=0; i<target.snapshotLength; i++) {</p>
target.snapshotItem(i).style.display = "none";
}
})();
// or contains(text(),'')
ついでにこの記事も消える
NGワードは適宜追加してください
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
最近はてなについて色々書いてあるけど、はてなは全般的にデザインが問題だと思う。
長く滞在したいとか、日々愛着があるツールとしては使いたくないデザインなんだよね。
決してサービスの機能とか技術が劣ってるわけじゃない、見せ方とデザインの問題、視覚的な見た目も含めたインターフェイスの問題なのよ。
「脱IT系」のデザインでもないし、ギーク受けする海外の様なCoolなデザインでもないし、Googleやzohoの様に洗練された統一的なデザインでもない。
むしろWeb0.5？みたいなデザインなんだよね。
deliciousとかflickrとかクラスのインターフェイスを一サービス毎に持たせられたら流行ると思うよ。
機能は十分なのよ、それを実現する技術力もある。
今ならそのデザインやインターフェイスを実現できる人材も雇えるでしょう。
