【重要】 mixi OpenID 提供終了のお知らせ - ニュース
カテゴリー別ニュース (743)mixi Connect (92)mixi OpenID (4)mixi Platform 共通 (69)mixiアプリ (560)mixiページアプリ (13)障害情報 (207)mixi Connect (16)mixi OpenID (1)mixi Platform 共通 (42)mixiアプリ (134)mixiページアプリ (8)重要なお知らせ (36) ※2016/1/22更新 : 提供終了日時を2016/2/22に変更しました 平素より mixi Platform をご利用いただきまして、誠にありがとうございます。 この度、mixi OpenID について、サービスの提供を終了させて頂く事となりました。 mixi OpenID は mixi 内のユーザ情報を外部サイトでの認証に使用するためのサービスです。 mixi OpenID << mixi
mixi脆弱性報告制度：評価対象外になったもの
WEB系の情報セキュリティ関連の学習メモです。メモなので他情報のポインタだけ、とかの卑怯な記事もあります。 ※2020.9 注記:本ブログの解説記事は内容が古くなっております。OWASP ZAPなどのソフトウェアの解説は現行バージョンの仕様から乖離している可能性があります。 mixi脆弱性報告制度で報告した脆弱性のうち、報告したけど評価対象外になったものをまとめます。 報告したけど評価対象外だった脆弱性 1.ショッパーズアイ コードインジェクション 報告日：2014年3月31日 評価結果連絡：2014年4月8日 弊社において既知の脆弱性であると判断、よって脆弱性報告制度の対象外 ※追記：この脆弱性は現在は対応済みです。mixiさんに問い合わせて脆弱性対応済みであることを確認してから記事を公開しました。 ※2014.4.16 23:00 本記事の反響がやたら大きくなってしまったのでコメントを
Tokyo TyrantによるHAハッシュDBサーバの構築 - mixi engineer blog
来年のバレンタインデーに、正確には「2009-02-14T08:31:30+09:00」に、UNIX時間が「1234567890」を迎えることを発見してちょっと嬉しいmikioです。さて、今回は高効率ハッシュデータベースサーバTokyo Tyrantを用いてHAハッシュデータベースを構築する手法についてご紹介します。ちょっと難しいし非常に長い内容なのですが、最後までお付き合いくださいませ。 可用性と保全性 HA（High Availability：高可用性）とは、可用性（Availability）が高いことです。それでは説明になっていないので詳しく言い替えますと、システムに障害が起きにくくすることと、たとえ障害が起きたとしてもできるだけ迅速に復旧できるようにすることです。データベース系のシステムはユーザのデータを管理するという中核的役割を担うため、可用性を高めることは最も重要な課題となりま
mixi Engineers’ Blog » libmemcachedで快速キャッシュ生活
みんな大好きなmemcached。今日はBrian AkerのC言語用クライエントライブラリについて書きたいと思います。日本語の情報がとても少なく、ドキュメンテーションも英語だけという事で興味はあるけど手をつけていないという方のお役に立てれたらなと思います。 本題の前に why libmemcached? 既にlibmemcacheが存在するのに何故、libmemcached？かと言うと理由の一つは最近libmemcacheの開発が止まったからです。本家ではそれが理由でlibmemcacheではなくlibmemcachedを推奨してますね。又、効率的なメモリ使用、Consistent Hashing、様々なハッシュアルゴリズム、新しいオペレータに対応している等という宣伝文句があります。apr_memcacheというライブラリも存在しますが自分は使った事がないためノーコメント。 ただ、推奨さ
mixi Engineers’ Blog » 新RSS Crawlerの裏側
このブログでは初めましての長野雅広(kazeburo)です。mixi開発部・運用グループでアプリケーションの運用を担当しています。 12月12日よりmixiのRSSのCrawlerが改善され、外部ブログの反映が今までと比べ格段にはやくなっているのに気付かれた方も多いかと思います。この改善されたRSS Crawlerの裏側について書きたいと思います 以前のCrawlerについて 以前のCrawlerは cronからbrokerと呼ばれるプログラムを起動 brokerはmember DBから全件、idをincrementしながら取得し、外部ブログが設定されていればcrawlerを起動(fork) crawlerはRSSを取得しDBに格納して終了 このような設計になっていました。 この設計の問題として、member DBを全件走査するという無駄な動作と、一件一件crawlerを起動するためオーバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
