「ZOHO」を含む日記 RSS

はてなキーワード: ZOHOとは

2021-04-30

anond:20210430021225

真面目で好感がもてる人だなあ。

しかOutlook + VBAとか地雷しかないよね・・・

2009年とかなら別だけど。

まあフツーならMicrosoft Bookingsやろなあ。

https://blog.formzu.com/microsoft_bookings

予算ということだが月2000円とかケチ会社なら早々にやめたほうがいいw

https://www.zoho.com/jp/bookings/pricing.html

個人的にはZoho BookingsにMS365と連携させるのがおすすめ

2021-04-22

10年以上使っていたSalesforceを止めた

きっかけはLightiningに上げようと色々調べてみたこと。

あいつかは上げないといけないからねえ。

立ち上げる度にLightingの画面に切り替わって催促されるしw。

色々試行錯誤してみた。そうしたら不便な点多々散見された。

その中でこれはキツいな、受け入れられないな、と感じたのが下の2つ。

その1 差し込み印刷が出来ない。

Salesforceに限らず古いバージョンで出来てたことが出来なくなるのは

経験ある方ならわかると思うがめちゃくちゃストレスよねぇ。

仕方ないのでテストも兼ねて弊社のプログラマーに頼んで作らせてみた。

DBの中身拾ってきてhtmlで整形する、という手法でやってみた。まあ出来るようにはなった。

なんだけどこの程度のことでわざわざプログラマーの手を煩わして

コーディングってのもちと違うよね。簡単に出来ることに手間かけるってのは本末転倒の極み。

おまけにAPI使うには追加費用必要云々言ってきた。まあそういう価格体系なんだろうけどそもそも使ってた機能

使えなくなったことが要因なのでこれには不満が残った。

お客様ライセンスでは開発のサポートは出来ません、みたいな連絡も頂いた。

これも正しいんだろうけど、たか差し込み印刷を開発というのもどうなのかと?

簡単なことをわざわざ「開発」しないと出来ないことがむしろ問題なので。

日本人って帳票沢山使う民族なのでこれ出来なくて困ってる人沢山いるんじゃないかな。

プラグイン作ってるとこは儲かるかもしれないが。

その2 ナレッジベース

公開ナレッジベースを長きに渡って使っていた。

が、なんと現行のナレッジベースとLightingの互換性がないらしい。

サポートに聞いてみると自分でローダー使って移してくださいと。出来ない場合は手で入力してくださいと。

何百件あるのを手で入力って言うのは簡単だけど現実的ではないよね。

勿論そういう仕様なんだから仕方ないとも言える。

が、そもそも同じソフト/サービスで新バージョンに移行するにあたって

ユーザにこういう不便を強いるってのおかしいよね。

あとそもそもローカルでそういう面倒なことやんなくていいのがクラウドメリットだったはず。

データ自分で移行しなきゃいけないなら他のシステムにいくのと変わらないと、判断

この時点で決心した。

それと今のライセンス(Professional)ではLightingに上げるとそもそもナレッジベース使えないらしい。

まり新しいほういくとライセンスを上のグレードに上げる必要がある。

まり実質的な値上げなんだけど、どこにも値上げと唄ってない。

こういうやり方、手法を取ったとしたらそれはベンダー側の判断。こっちが決めることじゃないので。

尊重しましょう。

が、いかにも後味悪い。遺恨を残す。なんだかなあと。

何故か怒りは全く湧いてこず一番良い手法

早く見つけようという気になった。SFサポート営業を責めても仕方ないしね。

彼らは彼らの仕事を真面目にやってるだけなんで。実際一生懸命やってくれたし。

感謝してますよ。

で、ZOHOデモ登録して色々試してみた。他のも色々見てみたけど

移行が簡単そうだったので。

途中引っかかる点もあったがサポートの力を借りながら全部のデータ無事に移行終了。

こちらで運用開始、そして今に至ってる。弊社はあんまり難しいことやってないからね。

カスタムオブジェクトがいくつかあるぐらい。あとはサブスクリプション管理の項目がなかったので

予め作っておいた。

結果は大満足。元々SFのバチもん(というと失礼だが最初

UIはそう言われても仕方ないと思う)、だったので中身よく似てる。

直ぐに使えるようになった。ぶっちゃけUIはこっちのほうが良いんじゃないかな。

これはあくま個人の好みだけど。

あとコストの点も大きい。

SFはずっと1人会社の頃から使ってて、会社が大きくなって人数増えてもユーザーは小生一人だけだった。

が、この先新規事業ユーザー増えてくのでその前に移っておいてホント良かったかなと。

10年以上使ってたシステムを移行するの躊躇した時もあったがやってみると

思いの外簡単だった。色々弄ってると今は使ってないテンプレートとか

出てきてああ、こんなことやってたなあと、感慨深かった。

からなかった、ダメだったビジネスも多々あるがw。

色々あったがSaleforceにはここで改めて礼を言っておこう。

新しい事業もやる気になってきた。仕事は楽しくやらないとね。

SF/CRM的なサービス今は沢山あるので自分にあったのを選べば良いと思う。

これから使おうと思っている人、会社使用中で移行を考えている人、会社の参考になればと。

2019-06-28

anond:20190628124649

それを言うならGmailじゃなくてwebメールでは?

だってwebメールありさえすれば、Gmailじゃなくて outlook.com でも Zohoメールでも何でもいいじゃん。

2018-04-30

ZOHO企業)のロゴ

こんなに外国感があって胡散臭そうなロゴは、今の時代になかなか無いよ。

2016-11-13

スパムの消し方を教える

1.TampermonkeyまたはGreasemonkeyを導入する

Tampermonkey

https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ja

Greasemonkey

https://addons.mozilla.org/de/firefox/addon/greasemonkey/


2.次のスクリプトを追加する

// ==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(),'')


3.スパム投稿が表示されなくなる

ついでにこの記事も消える

NGワードは適宜追加してください

参考

http://anond.hatelabo.jp/20070517234726

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」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 サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイル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

http://no-oauth.insanecoding.org/

2008-12-26

はてなは全般的にデザインが問題だと思う

最近はてなについて色々書いてあるけど、はてなは全般的にデザインが問題だと思う。

長く滞在したいとか、日々愛着があるツールとしては使いたくないデザインなんだよね。

決してサービスの機能とか技術が劣ってるわけじゃない、見せ方とデザインの問題、視覚的な見た目も含めたインターフェイスの問題なのよ。

「脱IT系」のデザインでもないし、ギーク受けする海外の様なCoolデザインでもないし、Googlezohoの様に洗練された統一的なデザインでもない。

むしろWeb0.5?みたいなデザインなんだよね。

deliciousとかflickrとかクラスインターフェイスを一サービス毎に持たせられたら流行ると思うよ。

機能は十分なのよ、それを実現する技術力もある。

結局ユーザーってインターフェイスや見た目が全てだからさ。

今ならそのデザインインターフェイスを実現できる人材も雇えるでしょう。

まず、「脱IT系」とかは意識するだけでいいから、真っ先にデザイン一新が必要だと思う。

 
ログイン ユーザー登録
ようこそ ゲスト さん