元スレ【PHP】下らねぇ質問はID出して書き込みやがれ 118

php覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

801 = :

>>798
当たり前
拡張子がjspとかdoとかのページ見たことないかね
まぁPHPとは開発方法も環境も大きく異なるから
簡単ではないよ
Javaめんどいし環境整えるだけで挫折するかもしれん

802 = :

実装が中途半端、継ぎ接ぎだらけ。

803 = :

>>779
IDが強制的に出る板がいいな

804 = :

>>798
twitterとかあるじゃん

805 = :

IDとかすぐかえれるし無意味
単発気味になるから特定は簡単だけど
やっぱIPだな
チンピラさん出番ですよ

806 = :

そうだな…せいぜい自演が管理者以外にも分かるぐらいか
マメに削除依頼を出すしかないか

808 = :

クールなサービスにバックエンドなんてどうでもいいからな
人数が多くなって初めてPHPが足を引っ張る程度
おまえらが開発するもんじゃPHPもJavaも変わらんってことよ

809 = :

お前らみんな死ねばいいのに

812 = :

>>805
お前ら一応技術者なんだからipくらい釣って抜けよ

813 = :

PHPが足引っ張ってるんじゃなくて、お前らの技術力のなさが足引っ張ってんだよ

814 = :

どうやらIP化は都合が悪いらしい。
つまり、荒らすのやめる気はないみたいだな

815 = :

お前らのようなカスには
カス言語のPHPがお似合い

816 = :

そのクズにこんなに粘着してるのが楽しくて仕方ないんだろう？

818 = :

都度DBから取る。

819 = :

mysql様が上手いことキャッシュしてくれるのを祈る

820 = :

PHPはキャッシュもできないクソ言語。
DB負荷強烈。だから遅い。

821 = :

>>817
ユーザー名みたいにほぼ常時に使うデータならセッションに入れてしまう
それ以外はローカルのファイルシステムに置いておくしかなかろう

822 = :

祈るだとか人任せ
それはPHPがクズだから

823 :

俗に言う「管理画面」ってどこまでの機能を用意するべきなのでしょうか？
例えば、会員の日記が投稿できるコンテンツがあったとして、
管理画面で日記の閲覧はもちろん、
日記の編集や削除も出来る機能を実装しておくべきなのでしょうか？

会員が投稿した文章や画像に問題があって管理責任を問われるケースが
近年増えたと思いますが、システム側ではどこまで用意するか気になっています

824 = :

企画次第
企画としてここまで必要と言われれば、あぁ、そうですね。
企画としてここまでは必要ないと言われれば、あぁ、そうですね。
まず、これが基本かと。

825 = :

規約次第じゃない？
投稿された内容は投稿者が全責任を負います、なのか
投稿された内容の著作権者が誰になるか、とか
当局が捜査する場合は問題がある内容を証拠として保全する必要がある、とか
いろいろ事情があるだろうし

非公開の日記を管理者が閲覧するのはどうなの？とか

826 = :

>>823
会員が爆破予告とかしたときに警察からの照会があったら答えられるようにしなきゃいけないんじゃないの？

827 = 823 :

>>824-826
例えばDBを使うシステムなら、管理画面で操作できなくても
サーバから実行してログを表示する事って出来ますよね？
ただ、CUIの画面なので分かりづらいですから、
GUIの管理画面が必要というのは分かります。

でも、管理画面・会員画面と2つあって、どちらも同じような機能を
2つ作るのもどうなのかな？と思ったりします。
Wordpressのように同じ管理画面から権限を変えて利用できる機能を
制限するってやり方もあるでしょうが、多くの人に公開する場合、
そもそも管理画面のURLを知られる事がまずいと言いますし

828 = :

知られるのがまずい理由は？

829 = 823 :

>>828
単純に不正アクセスの標的になりやすいからじゃないですかね
サーバのSSHのポートも22のままじゃなくて変更するし、
rootでログインできなくします。それと同じ認識かと

830 = :

共通の機能だったら1箇所にまとめればいいし、
会員が使うページと管理者が使うページを別のURLにして、
会員ページでは管理者ページにリンクしなければいいだけでしょ？
だったらそうするだけじゃないの

831 = :

>>827
> サーバから実行してログを表示する事って出来ますよね？
SQLとスキーマを知っていないと操作ができないぜ？面倒だぜ？
ヘンなデータを突っ込んで整合性を欠く状態になっても誰も教えてくれないぜ？おっかないぜ？
その状態でバックアップまで更新されてしまったら誰が責任を持つんだぜ？関わりたくないぜ？

> でも、管理画面・会員画面と2つあって、どちらも同じような機能を
> 2つ作るのもどうなのかな？と思ったりします。
面倒だからその分お金を上乗せするんだぜ？

832 = 823 :

>>830-831
なるほど。その考えは思い浮かびませんでした。

楽天とかamazonみたいな巨大システムでも
どの会員が何買ったとか、どの店がどんな商品出してるとか
そういう情報を把握する管理画面があるんですかね？

834 = 823 :

閲覧は出来ても編集や削除はユーザ判断に任せていると思ってました。
商品情報が編集出来るなら、変な疑念を抱くユーザもいるかもしれませんし・・・

835 = :

そういうのが必要で、その機能をつけた場合は、誰が編集できたか見えるようにするんだよ。

836 = :

権限を、○○を編集する権限、○○を削除する権限、のように分けて、
管理者・会員という単純な分け方ではなくユーザグループを細かく分けて、
各グループにどんな権限(複数)を与えるか決めて、
全体を運営するのが普通。

商品情報の編集機能が必要なら、
編集の権限を持つグループの人だけが編集できるようにして、
もちろん編集の履歴を保管する。
編集の履歴は、履歴を閲覧する権限を持つグループの人のみが閲覧できるようにする。

837 = 823 :

>>836
というのは「管理者（管理画面を操作できるユーザ）」の設定で、
それとは別に会員専用の画面があるという解釈で良いんですよね？

838 = :

これだけ説明してあげてるのに分かってないようだな

管理者画面のURLを会員に知られないようにするって上にあるだろ？

843 = :

俺なら使わないし、使うなって言う。
何ペインだろうが、iframeでないと出来ないものなんてないんだし

846 = :

phpにできないことはない

847 = :

ストーカーって言うより、
好きな子にちょっかい出し続ける小学生みたいだよ。

848 = :

あたしのことが好きなの？