网页登录界面设计
php登录页面的是怎么做的
1234567891011121314151617181920session_star();if(!isset($_SESSION['login_status'])) //不存在就直接login页面，你可以在每个页头加载这个来判断 header('Location:login.php');$username=$_POST['name'];$pass=$_POST['password']; $sql="select * from 用户表单 where username='{$username}'";$result=mysql_query($sql,$link); if($result && mysql_num_rows($result)>0){ //判断用户名是否存在 $user=mysql_fetch_assoc($result); if($user['pass']==md5($pass)){ $_SESSION['login_status'] = 1 //让后续判断是不是已经登录了(存放在服务器端，关闭浏览器就没有,或者你可以用cookie来判断) echo '登录成功！'; }else{ echo "密码错误！"; }}else{ echo "账号不存在！"; }代码写的很好，但是是个初学者，对session对话还不是很了解，所以不能完全看懂你的代码。非常感谢你做的回答。
请问做后台界面设计用多大的设计尺寸合适？
尽量大些，前端可以按需求自适应 你可以做个大到1920尺寸宽的设计图
哦哦好的，我之前问的那个尺寸，按照做了以后我发现前端是用的尺寸跟我不一样，然后我就只能再改，所以我才有点疑惑，谢谢解答
不客气，反正做大点儿没关系，前端切出来代码可以随时改宽度，影响不大，但是做小了就不好办了，多沟通，就能解决好问题
应用提交 App Store 上架被拒的原因都有哪些
1号大坑：检测更新苏立：第5点，我看到有些app还是在app内有检测更新，他们是如何做到的？闫国荣：检测更新这个本来是标配功能，但是在3月开始以来的审核中要求不能加入。你们看到的很多支持检测更新是之前的版本，现在上架的新产品严格控制这条，当然啦，现在更新版本有一部分漏网之鱼。抽屉：检测更新连TestFlight都会被拒绝。2号大坑：和系统接近的图标效果Kun：生活日历之前标志用了一年多，直到苹果推出通知中心以后，说我们的标志和他们像就被打回了，改了很多版本，颜色图形各种改都不给过，最后直接换了一个标志；另外app推荐也不能用，一般用服务器控制，通过后再上；安卓的字眼不能有……3号大坑：使用登录会进入引导下载页面，结果被苹果退回审核治愈猫：补充我们遇到的一种情况，我们用了第三方登陆，如果用户没有安装的话，使用登录会进入引导下载页面，结果被苹果退回审核。4号大坑：广告原因导致被拒柴Crystal：上周提交一款产品，里面有广告代码，但是没有显示广告，也被退回了。闫国荣：恩，因为你们可能调用了它的IDFA的相关东西。就算没广告的展现，但是苹果也发现你们调用了，就会说你们有广告。接着说友盟的问题：友盟为了逃避苹果的审核，在后台默认做了一个淘宝的全屏广告，不过在3月之前都可以过，但在3月之后，苹果也要拒，因为很多产品和淘宝的广告不符合。比如我是糗百，弹出一个淘宝广告，苹果也会拒绝。所以一般有两种做法：①采用友盟的无IDFA的sdk，不过无IDFA的sdk对统计会有误差。②自己做个banner广告，审核过了后台修改参数，隐藏。5号大坑：出现第三方操作系统的名字或图标第三方操作系统的图标或者名字，不能出现在应用内。例如出现Android的图标关键字被拒，这个遇到过么？闫国荣：你的app截图也最好不用android手机壳子，android的也不要用iphone状态栏。在各个市场，都不允许出现对方系统的东西，我们android之前偷懒，用了iOS宣传图，也被android市场拒绝过，因为状态栏是iOS的。Kun：产品描述中提到安卓，就被拒了。张涛Soloer：上传应用截图时，如果是上传百度市场，截图状态栏能看到应用宝图标，会被拒绝的。iOS版本，做了一个付费版，和原有版本策略不同，但是appstore拒绝了，理由是和旧有版本功能一致其实，竞品都是那么做的，已经上线了。这是我遇到的两种情况。6号大坑：注册登录，性别和头像非必填闫国荣：“没有帮注册用户默认性别和头像（不支持跳过）“，这个问题不知道你们遇到过没，我才遇到的，略坑。和苹果交流了很多次，最后屈服了。注册的时候现在多数app是必须用户完成头像、性别信息的。60%都不可以跳过，但是我们这次审核的时候，不行了。苹果要求性别和头像都可以非必填，大家最近上架的要注意这条，当然审核员尺度不一样，很难说。7号大坑：软硬件结合的产品，一定要拍摄视频或者寄送硬件给苹果检测陈宇强：早年做智能可穿戴设备时，因为需要硬件和软件整合才能使用，苹果以软件无法测试为由拒绝了。后来苹果要求把硬件寄到没过来完成软件的测试。8号大坑：界面太丑，宣传太过，跟风明显会被拒界面太丑的情况也有被拒绝过，产品没新意也是被拒的一个原因。高威煌：太丑真的会被拒么？Roger：这是真的。Reggie：宣传图片过度，也会被拒闫国荣：再说个大家记得不？当年那个bird不是很火么，然后大批类似商家，苹果都拒绝了。我还要说一点，大家注意！我提到我们有写苹果婊被拒，其实有的朋友，写2逼都会被拒，我也试过2逼，苹果不行。还有朋友的产品里面有一个图是竖起中指的，也被拒。付平非：是的，我们写了逗比、牛逼、绿茶婊，被拒了三次，也是无语了。9号大坑：内容型 app遇到版权问题，怎么破Roger：先交代下背景，我这边负责的是视频聚合类的应用，主要是各种美剧、英剧。在第一次提交被打回，原因是应用会出现崩溃的情况，所以在这里提醒大家：在提交苹果审核的时候，一定要做好测试。10号大坑：支付、文案等问题导致被拒如果还有大坑，欢迎私信@胡澈 或者在文章下面留言，我们会尽量维护一个更棒的列表，方便大家查询。应用提交 App Store 上架被拒的原因都有哪些
小米空气净化器支持5gwifi吗
小米空气净化器支持5gwifi的正确连接方法如下：打开小米净化器，小米净化器立刻将自己无线网卡设置为AP状态，它的SSID和密码都已经存储在服务器上；手机的小米APP进行扫描，侦测到小米净化器AP的SSID，用云端或本地库检索到的对应密码连接小米净化器AP并进入设置界面（就是你点添加新设备后，要输入无线密码的界面）；此时，你在APP上输入家中SSID和AP密码，会存储到小米净化器中，小米净化器退出自己的AP状态，连接家中AP，连接成功；今后手机APP的所有命令将通过云端送达净化器（同一局域网状态似乎可以直连）。
网页设计中用户登陆设计时怎样与数据库连接？
<%Dim connweb, connstrconnstr = "provider=sqloledb;data source=IP地址或机器名;uid=用户名;pwd=登录密码;database=数据库名;"Set connweb = server.createobject("adodb.connection")connweb.open connstr%>
HTML中做了一个用户登录，要怎么能让登录窗口在页面中间显示
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" mrc="text/html; charset=gb2312" /><title>始终居中的弹出层- www.mb5u.com</title><style type="text/css"><!--html,body {height:100%; margin:0px; font-size:12px;}.mydiv {background-color: #FFCC66;border: 1px solid #f00;text-align: center;line-height: 40px;font-size: 12px;font-weight: bold;z-index:999;width: 300px;height: 120px;left:50%;top:50%;margin-left:-150px!important;/*FF IE7 该值为本身宽的一半 */margin-top:-60px!important;/*FF IE7 该值为本身高的一半*/margin-top:0px;position:fixed!important;/* FF IE7*/position:absolute;/*IE6*/_top: expression(eval(document.compatMode && document.compatMode=='CSS1Compat') ? documentElement.scrollTop + (document.documentElement.clientHeight-this.offsetHeight)/2 :/*IE6*/ document.body.scrollTop + (document.body.clientHeight - this.clientHeight)/2);/*IE5 IE5.5*/}.bg,.popIframe {background-color: #666; display:none;width: 100%;height: 100%;left:0;top:0;/*FF IE7*/filter:alpha(opacity=50);/*IE*/opacity:0.5;/*FF*/z-index:1;position:fixed!important;/*FF IE7*/position:absolute;/*IE6*/_top: expression(eval(document.compatMode && document.compatMode=='CSS1Compat') ? documentElement.scrollTop + (document.documentElement.clientHeight-this.offsetHeight)/2 :/*IE6*/ document.body.scrollTop + (document.body.clientHeight - this.clientHeight)/2);/* www.mb5u.com IE5 IE5.5*/}.popIframe {filter:alpha(opacity=0);/*IE*/opacity:0;/*FF*/}--></style><script language="javascript" type="text/javascript">function showDiv(){document.getElementById('popDiv').style.display='block';document.getElementById('popIframe').style.display='block';document.getElementById('bg').style.display='block';}function closeDiv(){document.getElementById('popDiv').style.display='none';document.getElementById('bg').style.display='none';document.getElementById('popIframe').style.display='none';}</script></head><body><div id="popDiv" class="mydiv" style="display:none;">网页设计大本营欢迎你！<br/>Q群号:29032448<br/><a href="javascript:closeDiv()">关闭窗口</a></div><div id="bg" class="bg" style="display:none;"></div><a href="javascript:showDiv()">点击这里弹出层</a><iframe id='popIframe' class='popIframe' frameborder='0' ></iframe></body></html>
网页设计中用户登陆设计时怎样与数据库连接？
<%Dim connweb, connstrconnstr = "provider=sqloledb;data source=IP地址或机器名;uid=用户名;pwd=登录密码;database=数据库名;"Set connweb = server.createobject("adodb.connection")connweb.open connstr%>
想用html做一个静态登录界面，可以验证密码的。
参考下面代码<form method="post" action="###" name="myform" onsubmit="checkpost()"><label for="name">用户名：</label><input type="text" name="name" id="name" /><br /><label for="pw">密码：</label><input type="password" name="pw" id="pw" /><br /><input type="submit" value="提交" /></form><script>function checkpost(){if(document.forms[0].name.value=="要的用户名"&&document.forms[0].pw.value=="要的密码"){window.location="要跳转的地址";}else{alert("用户名或密码不正确！")return false;}}</script>
如何设计安全的用户登录功能
Web上的用户登录功能应该是最基本的功能了，可是在我看过一些站点的用户登录功能后，我觉得很有必要写一篇文章教大家怎么来做用户登录功能。下面的文章告诉大家这个功能可能并没有你所想像的那么简单，这是一个关系到用户安全的功能，希望大家能从下面的文章中能知道什么样的方法才是一个好的用户登录功能。 用户名和口令 首先，我们先来说说用户名和口令的事。这并不是本站第一次谈论这个事了。如何管理自己的口令让你知道怎么管理自己的口令，破解你的口令让你知道在现代这样速度的计算速度下，用穷举法破解你的口令可能会是一件很轻松的事。在这里我想告诉从开发者的角度上来做设计这个用户名和口令的事。下面一几件规则： 限制用户输入一些非常容易被破解的口令。如什么qwert，123456, password之类，就像twitter限制用户的口令一样做一个口令的黑名单。另外，你可以限制用户口令的长度，是否有大小写，是否有数字，你可以用你的程序做一下校验。当然，这可能会让用户感到很不爽，所以，现在很多网站都提供了UX让用户知道他的口令强度是什么样的（比如这个有趣的UX），这样可以让用户有一个选择，目的就是告诉用户——要想安全，先把口令设得好一点。 千万不要明文保存用户的口令。正如如何管理自己的口令所说的一样，很多时候，用户都会用相同的ID相同的口令来登录很多网站。所以，如果你的网站明文保存的话，那么，如果你的数据被你的不良员工流传出去那对用户是灾难性的。所以，用户的口令一定要加密保存，最好是用不可逆的加密，如MD5或是SHA1之类的有hash算法的不可逆的加密算法。CSDN曾明文保存过用户的口令。（另，对于国内公司的品行以及有关部门的管理方式，我不敢保证国内网站以加密的方式保存你的口令。我觉得，做为一个有良知的人，我们应该加密保存用户的口令） 是否让浏览器保存口令。我们有N多的方法可以不让浏览器保存用户名和口令。但是这可能对用户来说很不爽。因为在真实世界里谁也记得不住那么多的口令。很多用户可能会使用一些密码管理工具来保存密码，浏览器只是其中一种。是否让浏览器保存这个需要你做决定，重点是看一下你的系统的安全级别是否要求比较高，如果是的话，则不要让浏览器保存密码，并在网站明显的位置告诉用户——保存口令最安全的地方只有你的大脑。 口令在网上的传输。因为HTTP是明文协议，所以，用户名和口令在网上也是明文发送的，这个很不安全。你可以看看这篇文章你就明白了。要做到加密传输就必需使用HTTPS协议。但是，在中国还是有很多网站的Web登录方式还在使用ActiveX控件，这可能成为IE6还大量存在的原因。我通常理解为这些ActiveX控件是为了反键盘记录程序的。不过，我依然觉ActiveX控件不应该存在，因为在国外的众多安全很重要的站点上都看不到ActiveX的控件的身影。 用户登录状态 首先，我想告诉大家的是，因为HTTP是无状态的协议，也就是说，这个协议是无法记录用户访问状态的，其每次请求都是独立的无关联的，一笔是一笔。而我们的网站都是设计成多个页面的，所在页面跳转过程中我们需要知道用户的状态，尤其是用户登录的状态，这样我们在页面跳转后我们才知道是否可以让用户有权限来操作一些功能或是查看一些数据。 所以，我们每个页面都需要对用户的身份进行认证。当然，我们不可能让用户在每个页面上输入用户名和口令，这会让用户觉得我们的网站相当的SB。为了实现这一功能，用得最多的技术就是浏览器的cookie，我们会把用户登录的信息存放在客户端的cookie里，这样，我们每个页面都从这个cookie里获得用户是否登录的信息，从而达到记录状态，验证用户的目的。但是，你真的会用cookie吗？下面是使用cookie的一些原则。 千万不要在cookie中存放用户的密码。加密的密码都不行。因为这个密码可以被人获取并尝试离线穷举。所以，你一定不能把用户的密码保存在cookie中。我看到太多的站点这么干了。 正确设计“记住密码”。这个功能简直就是一个安全隐患，我觉得并不是所有的程序员都知道怎么设计这个事。一般的设计是——一时用户勾选了这个功能，系统会生成一个cookie，cookie包括用户名和一个固定的散列值，这个固定的散列值一直使用。这样，你就可以在所有的设备和客户上都可以登录，而且可以有多个用户同时登录。这个并不是很安全。下面是一些更为安全的方法供你参考： （——更新 2011/08/26，原文中有些小错误，并且说的不清楚，重新调整了一下——） 1）在cookie中，保存三个东西——用户名，登录序列，登录token。 用户名：明文存放。 登录序列：一个被MD5散列过的随机数，仅当强制用户输入口令时更新（如：用户修改了口令）。 登录token：一个被MD5散列过的随机数，仅一个登录session内有效，新的登录session会更新它。 2）上述三个东西会存在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。 3）这样的设计会有什么样的效果，会有下面的效果， a）登录token是单实例登录。意思就是一个用户只能有一个登录实例。 b）登录序列是用来做盗用行为检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录token”，而真正的用户回来访问时，系统发现只有“用户名”和“登录序列”相同，但是“登录token”不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况，于是，系统可以清除并更改登录序列 和 登录token，这样就可以令所有的cookie失效，并要求用户输入口令。并给警告用户系统安全。 4）当然，上述这样的设计还是会有一些问题，比如：同一用户的不同设备登录，甚至在同一个设备上使用不同的浏览器保登录。一个设备会让另一个设备的登录token和登录序列失效，从而让其它设备和浏览器需要重新登录，并会造成cookie被盗用的假象。所以，你在服务器服还需要考虑- IP 地址， a）如果以口令方式登录，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为口令只有真正的用户知道。 b）如果 IP相同 ，那么，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为是同一用户有同一IP（当然，同一个局域网里也有同一IP，但我们认为这个局域网是用户可以控制的。网吧内并不推荐使用这一功能）。 c）如果（IP不同 &&没有用口令登录），那么，“登录token”就会在多个IP间发生变化（登录token在两个或多个ip间被来来回回的变换），当在一定时间内达到一定次数后，系统才会真正觉得被盗用的可能性很高，此时系统在后台清除“登录序列”和“登录token“，让Cookie失效，强制用户输入口令（或是要求用户更改口令），以保证多台设备上的cookie一致。 不要让cookie有权限访问所有的操作。否则就是XSS攻击，这个功能请参看新浪微博的XSS攻击。下面的这些功能一定要用户输入口令： 1）修改口令。 2）修改电子邮件。（电子邮件通过用来找回用户密码） 3）用户的隐私信息。 4）用户消费功能。 权衡Cookie的过期时间。如果是永不过期，会有很不错的用户体验，但是这也会让用户很快就忘了登录密码。如果设置上过期期限，比如2周，一个月，那么可能会好一点，但是2周和一个月后，用户依然会忘了密码。尤其是用户在一些公共电脑上，如果保存了永久cookie的话，等于泄露了帐号。所以，对于cookie的过期时间我们还需要权衡。 找回口令的功能 找回口令的功能一定要提供。但是很多朋友并不知道怎么来设计这个功能。我们有很多找回口令的设计，下面我逐个点评一下。 千万不要使用安全问答。事实证明，这个环节很烦人，而且用户并不能很好的设置安全问答。什么，我的生日啊，我母亲的生日，等等。因为今天的互联网和以前不一样了，因为SNS，今天的互联比以前更真实了，我可以上facebook，开心，人人网，LinkedIn查到你的很多的真实的信息。通过这些信息我可以使用安全问答来重设你的口令。这里需要说一下 Facebook，Facebook的安全问答很强大，还要你通过照片认人，呵呵。 不要重置用户的密码。因为这有可能让用户的密码遭到恶意攻击。当然，你要发个邮件给用户让其确认，用户点击邮件中的一个链接，你再重置。我并不推荐这样的方法，因为用户一般都会用笔记下来这个很难记的口令，然后登录系统，因为登录系统时使用了“记住密码”的功能，所以导致用户不会去修改密码，从而要么导到被写下来的密码被人盗取，要么又忘记了密码。 好一点的做法——通过邮件自行重置。当用户申请找回口令功能的时候，系统生成一个MD5唯一的随机字串（可通过UID+IP+timestamp+随机数），放在数据库中，然后设置上时限（比如1小时内），给用户发一个邮件，这个连接中包含那个MD5的字串的链接，用户通过点击那个链接来自己重新设置新的口令。 更好一点的做法——多重认证。比如：通过手机+邮件的方式让用户输入验证码。手机+邮件可能还不把握，因为手机要能会丢了，而我的手机可以访问我的邮箱。所以，使用U盾，SecureID（一个会变化的6位数token），或是通过人工的方式核实用户身份。当然，这主要看你的系统的安全级别了。 口令探测防守 使用验证码。验证码是后台随机产生的一个短暂的验证码，这个验证码一般是一个计算机很难识别的图片。这样就可以防止以程序的方式来尝试用户的口令。事实证明，这是最简单也最有效的方式。当然，总是让用户输入那些肉眼都看不清的验证码的用户体验不好，所以，可以折中一下。比如Google，当他发现一个IP地址发出大量的搜索后，其会要求你输入验证码。当他发现同一个IP注册了3个以上的gmail邮箱后，他需要给你发短信方式或是电话方式的验证码。 用户口令失败次数。调置口令失败的上限，如果失败过多，则把帐号锁了，需要用户以找回口令的方式来重新激活帐号。但是，这个功能可能会被恶意人使用。最好的方法是，增加其尝试的时间成本（以前的这篇文章说过一个增加时间成本的解密算法）。如，两次口令尝试的间隔是5秒钟。三次以上错误，帐号被临时锁上30秒，5次以上帐号被锁1分钟，10次以上错误帐号被锁4小时…… 系统全局防守。上述的防守只针对某一个别用户。恶意者们深知这一点，所以，他们一般会动用“僵尸网络”轮着尝试一堆用户的口令，所以上述的那种方法可能还不够好。我们需要在系统全局域上监控所有的口令失败的次数。当然，这个需要我们平时没有受到攻击时的数据做为支持。比如你的系统，平均每天有5000次的口令错误的事件，那么你可以认为，当口令错误大幅超过这个数后，而且时间相对集中，就说明有黑客攻击。这个时候你怎么办？一般最常见使用的方法是让所有的用户输错口令后再次尝试的时间成本增加。 最后，再说一下，关于用户登录，使用第三方的 OAuth 和 OpenID 也不失为一个很不错的选择。
