私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】下らねぇ質問はID出して書き込みやがれ 118
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>779
IDが強制的に出る板がいいな
IDが強制的に出る板がいいな
>>798
twitterとかあるじゃん
twitterとかあるじゃん
IDとかすぐかえれるし無意味
単発気味になるから特定は簡単だけど
やっぱIPだな
チンピラさん出番ですよ
単発気味になるから特定は簡単だけど
やっぱIPだな
チンピラさん出番ですよ
そうだな…せいぜい自演が管理者以外にも分かるぐらいか
マメに削除依頼を出すしかないか
マメに削除依頼を出すしかないか
クールなサービスにバックエンドなんてどうでもいいからな
人数が多くなって初めてPHPが足を引っ張る程度
おまえらが開発するもんじゃPHPもJavaも変わらんってことよ
人数が多くなって初めてPHPが足を引っ張る程度
おまえらが開発するもんじゃPHPもJavaも変わらんってことよ
>>805
お前ら一応技術者なんだからipくらい釣って抜けよ
お前ら一応技術者なんだからipくらい釣って抜けよ
PHPが足引っ張ってるんじゃなくて、お前らの技術力のなさが足引っ張ってんだよ
どうやらIP化は都合が悪いらしい。
つまり、荒らすのやめる気はないみたいだな
つまり、荒らすのやめる気はないみたいだな
phpってmemcachedが使用できない環境のとき、DBから取ってきたデータは
どこに格納するのしょう?静的ファイルなんかにしているのでしょうか?
どこに格納するのしょう?静的ファイルなんかにしているのでしょうか?
俗に言う「管理画面」ってどこまでの機能を用意するべきなのでしょうか?
例えば、会員の日記が投稿できるコンテンツがあったとして、
管理画面で日記の閲覧はもちろん、
日記の編集や削除も出来る機能を実装しておくべきなのでしょうか?
会員が投稿した文章や画像に問題があって管理責任を問われるケースが
近年増えたと思いますが、システム側ではどこまで用意するか気になっています
例えば、会員の日記が投稿できるコンテンツがあったとして、
管理画面で日記の閲覧はもちろん、
日記の編集や削除も出来る機能を実装しておくべきなのでしょうか?
会員が投稿した文章や画像に問題があって管理責任を問われるケースが
近年増えたと思いますが、システム側ではどこまで用意するか気になっています
企画次第
企画としてここまで必要と言われれば、あぁ、そうですね。
企画としてここまでは必要ないと言われれば、あぁ、そうですね。
まず、これが基本かと。
企画としてここまで必要と言われれば、あぁ、そうですね。
企画としてここまでは必要ないと言われれば、あぁ、そうですね。
まず、これが基本かと。
規約次第じゃない?
投稿された内容は投稿者が全責任を負います、なのか
投稿された内容の著作権者が誰になるか、とか
当局が捜査する場合は問題がある内容を証拠として保全する必要がある、とか
いろいろ事情があるだろうし
非公開の日記を管理者が閲覧するのはどうなの?とか
投稿された内容は投稿者が全責任を負います、なのか
投稿された内容の著作権者が誰になるか、とか
当局が捜査する場合は問題がある内容を証拠として保全する必要がある、とか
いろいろ事情があるだろうし
非公開の日記を管理者が閲覧するのはどうなの?とか
>>823
会員が爆破予告とかしたときに警察からの照会があったら答えられるようにしなきゃいけないんじゃないの?
会員が爆破予告とかしたときに警察からの照会があったら答えられるようにしなきゃいけないんじゃないの?
>>824-826
例えばDBを使うシステムなら、管理画面で操作できなくても
サーバから実行してログを表示する事って出来ますよね?
ただ、CUIの画面なので分かりづらいですから、
GUIの管理画面が必要というのは分かります。
でも、管理画面・会員画面と2つあって、どちらも同じような機能を
2つ作るのもどうなのかな?と思ったりします。
Wordpressのように同じ管理画面から権限を変えて利用できる機能を
制限するってやり方もあるでしょうが、多くの人に公開する場合、
そもそも管理画面のURLを知られる事がまずいと言いますし
例えばDBを使うシステムなら、管理画面で操作できなくても
サーバから実行してログを表示する事って出来ますよね?
ただ、CUIの画面なので分かりづらいですから、
GUIの管理画面が必要というのは分かります。
でも、管理画面・会員画面と2つあって、どちらも同じような機能を
2つ作るのもどうなのかな?と思ったりします。
Wordpressのように同じ管理画面から権限を変えて利用できる機能を
制限するってやり方もあるでしょうが、多くの人に公開する場合、
そもそも管理画面のURLを知られる事がまずいと言いますし
共通の機能だったら1箇所にまとめればいいし、
会員が使うページと管理者が使うページを別のURLにして、
会員ページでは管理者ページにリンクしなければいいだけでしょ?
だったらそうするだけじゃないの
会員が使うページと管理者が使うページを別のURLにして、
会員ページでは管理者ページにリンクしなければいいだけでしょ?
だったらそうするだけじゃないの
>>827
> サーバから実行してログを表示する事って出来ますよね?
SQLとスキーマを知っていないと操作ができないぜ?面倒だぜ?
ヘンなデータを突っ込んで整合性を欠く状態になっても誰も教えてくれないぜ?おっかないぜ?
その状態でバックアップまで更新されてしまったら誰が責任を持つんだぜ?関わりたくないぜ?
> でも、管理画面・会員画面と2つあって、どちらも同じような機能を
> 2つ作るのもどうなのかな?と思ったりします。
面倒だからその分お金を上乗せするんだぜ?
> サーバから実行してログを表示する事って出来ますよね?
SQLとスキーマを知っていないと操作ができないぜ?面倒だぜ?
ヘンなデータを突っ込んで整合性を欠く状態になっても誰も教えてくれないぜ?おっかないぜ?
その状態でバックアップまで更新されてしまったら誰が責任を持つんだぜ?関わりたくないぜ?
> でも、管理画面・会員画面と2つあって、どちらも同じような機能を
> 2つ作るのもどうなのかな?と思ったりします。
面倒だからその分お金を上乗せするんだぜ?
>>830-831
なるほど。その考えは思い浮かびませんでした。
楽天とかamazonみたいな巨大システムでも
どの会員が何買ったとか、どの店がどんな商品出してるとか
そういう情報を把握する管理画面があるんですかね?
なるほど。その考えは思い浮かびませんでした。
楽天とかamazonみたいな巨大システムでも
どの会員が何買ったとか、どの店がどんな商品出してるとか
そういう情報を把握する管理画面があるんですかね?
閲覧は出来ても編集や削除はユーザ判断に任せていると思ってました。
商品情報が編集出来るなら、変な疑念を抱くユーザもいるかもしれませんし・・・
商品情報が編集出来るなら、変な疑念を抱くユーザもいるかもしれませんし・・・
そういうのが必要で、その機能をつけた場合は、誰が編集できたか見えるようにするんだよ。
権限を、○○を編集する権限、○○を削除する権限、のように分けて、
管理者・会員という単純な分け方ではなくユーザグループを細かく分けて、
各グループにどんな権限(複数)を与えるか決めて、
全体を運営するのが普通。
商品情報の編集機能が必要なら、
編集の権限を持つグループの人だけが編集できるようにして、
もちろん編集の履歴を保管する。
編集の履歴は、履歴を閲覧する権限を持つグループの人のみが閲覧できるようにする。
管理者・会員という単純な分け方ではなくユーザグループを細かく分けて、
各グループにどんな権限(複数)を与えるか決めて、
全体を運営するのが普通。
商品情報の編集機能が必要なら、
編集の権限を持つグループの人だけが編集できるようにして、
もちろん編集の履歴を保管する。
編集の履歴は、履歴を閲覧する権限を持つグループの人のみが閲覧できるようにする。
これだけ説明してあげてるのに分かってないようだな
管理者画面のURLを会員に知られないようにするって上にあるだろ?
管理者画面のURLを会員に知られないようにするって上にあるだろ?
業務システムで左側にメニュー、右上に一覧、右下に詳細という3ペイン構成にしたい場合、
frameタグ使いますか?
frameタグは使うなという風潮ですが、どうしても使いたい場合もけっこうあると思うんですよね。
業務システムなのでユーザーの環境は完全に特定できます。
フレームワークは使ってません。
frameタグ使いますか?
frameタグは使うなという風潮ですが、どうしても使いたい場合もけっこうあると思うんですよね。
業務システムなのでユーザーの環境は完全に特定できます。
フレームワークは使ってません。
すいません、ID出てませんでした。
俺なら使わないし、使うなって言う。
何ペインだろうが、iframeでないと出来ないものなんてないんだし
何ペインだろうが、iframeでないと出来ないものなんてないんだし
>>823
うちは通常の書込みに支障が出るくらい禁止ワード設定しまくってる。
で重要なのは、実際作ってもそんないたずらされるほどアクセス数稼げるような
サイトなんてよほど大々的に宣伝しないとありえない。99.9999%杞憂に終わる
実際サービス開始して重い汁ことになる
うちは通常の書込みに支障が出るくらい禁止ワード設定しまくってる。
で重要なのは、実際作ってもそんないたずらされるほどアクセス数稼げるような
サイトなんてよほど大々的に宣伝しないとありえない。99.9999%杞憂に終わる
実際サービス開始して重い汁ことになる
ストーカーって言うより、
好きな子にちょっかい出し続ける小学生みたいだよ。
好きな子にちょっかい出し続ける小学生みたいだよ。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- 【PHP】下らねぇ質問はID出して書き込みやがれ 119 (1001) - [98%] - 2012/6/21 11:46
- 【PHP】下らねぇ質問はID出して書き込みやがれ 138 (991) - [98%] - 2015/1/6 8:00
- 【PHP】下らねぇ質問はID出して書き込みやがれ 117 (1001) - [98%] - 2012/4/23 19:01
- 【PHP】下らねぇ質問はID出して書き込みやがれ 116 (1001) - [98%] - 2012/3/21 18:01
- 【PHP】下らねぇ質問はID出して書き込みやがれ 115 (1001) - [98%] - 2012/2/25 18:31
- 【PHP】下らねぇ質問はID出して書き込みやがれ 114 (1001) - [98%] - 2012/1/19 12:30
- 【PHP】下らねぇ質問はID出して書き込みやがれ 113 (1001) - [98%] - 2012/1/1 1:00
- 【PHP】下らねぇ質問はID出して書き込みやがれ 112 (1001) - [98%] - 2011/11/29 4:02
- 【PHP】下らねぇ質問はID出して書き込みやがれ 111 (1001) - [98%] - 2011/10/30 20:31
- 【PHP】下らねぇ質問はID出して書き込みやがれ 110 (1001) - [98%] - 2011/9/29 22:31
- 【PHP】下らねぇ質問はID出して書き込みやがれ 108 (1001) - [98%] - 2011/7/27 14:48
- 【PHP】下らねぇ質問はID出して書き込みやがれ 128 (1001) - [98%] - 2013/8/4 14:01
- 【PHP】下らねぇ質問はID出して書き込みやがれ 123 (1001) - [96%] - 2012/11/20 5:30
- 【PHP】下らねぇ質問はID出して書き込みやがれ 121 (1001) - [96%] - 2012/8/14 7:45
- 【PHP】下らねぇ質問はID出して書き込みやがれ 132 (1000) - [96%] - 2014/6/18 20:58
- 【PHP】下らねぇ質問はID出して書き込みやがれ 120 (1001) - [96%] - 2012/7/25 6:45
- 【PHP】下らねぇ質問はID出して書き込みやがれ 124 (1001) - [96%] - 2013/1/10 6:30
トップメニューへ / →のくす牧場書庫について