Jwt (JSON Web Token)自动延长过期

I would like to implement JWT-based authentication to our new REST API. But since the expiration is set in the token, is it possible to automatically prolong it? I don't want users to need to sign in after every X minutes if they were actively using the application in that period. That would be a huge UX fail.

But prolonging the expiration creates a new token (and the old one is still valid until it expires). And generating a new token after each request sounds silly to me. Sounds like a security issue when more than one token is valid at the same time. Of course I could invalidate the old used one using a blacklist but I would need to store the tokens. And one of the benefits of JWT is no storage.

I found how Auth0 solved it. They use not only JWT token but also a refresh token: https://docs.auth0.com/refresh-token

But again, to implement this (without Auth0) I'd need to store refresh tokens and maintain their expiration. What is the real benefit then? Why not have only one token (not JWT) and keep the expiration on the server?

Are there other options? Is using JWT not suited for this scenario?

转载于:https://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration

csdnceshi53
Lotus@ For SPA, checkout my blog post: blog.wong2.me/2017/02/20/refresh-auth0-token-in-spa
接近 3 年之前 回复
csdnceshi71
Memor.の Actually there is probably no security issue with many valid tokens at once... There are actually infinite number of valid tokens... So, why to have a refresh token then? I will regenerate them after each request, it should actually be not an issue.
大约 5 年之前 回复

9个回答

I work at Auth0 and I was involved in the design of the refresh token feature.

It all depends on the type of application and here is our recommended approach.

Web applications

A good pattern is to refresh the token before it expires.

Set the token expiration to one week and refresh the token every time the user open the web application and every one hour. If a user doesn't open the application for more than a week, they will have to login again and this is acceptable web application UX.

To refresh the token your API needs a new endpoint that receives a valid, not expired JWT and returns the same signed JWT with the new expiration field. Then the web application will store the token somewhere.

Mobile/Native applications

Most native applications do login once and only once.

The idea is that the refresh token never expires and it can be exchanged always for a valid JWT.

The problem with a token that never expires is that never means never. What do you do if you lose your phone? So, it needs to be identifiable by the user somehow and the application needs to provide a way to revoke access. We decided to use the device's name, e.g. "maryo's iPad". Then the user can go to the application and revoke access to "maryo's iPad".

Another approach is to revoke the refresh token on specific events. An interesting event is changing the password.

We believe that JWT is not useful for these use cases so we use a random generated string and we store it on our side.

csdnceshi59
ℙℕℤℝ From my experience, to refresh the token every time the user open the web application it's not good practice. When using one tab of application it's will be good, but when you use a few tabs or a few browsers it's will be a problem and causes tokens conflicts and disconnect all others application windows you use.
一年多之前 回复
csdnceshi80
胖鸭 Can the the iat ("issued at" seconds-since-epoch) value be updated with the refreshed JWT (you mention the exp value should be updated, but what about iat?)
接近 2 年之前 回复
csdnceshi70
笑故挽风 for you, I think you can do what I do when I need to gen any recovery code: - create a string field in the database; - generate a UUIDv4 uuid (random); - remove hyphen ("-") from the UUIDv4; - Base62 the UUIDv4 for a shorter url/humanized code; - bcrypt the Base62 of the UUIDv4 without hyphens; - store the bcrypt hash in the database; - send the Base62 as code for recovery e-mail, refresh tokens etc; - receive the code, use bcrypt to verify it against the hash stored in the database. Automated, 32 chars, URL friendly, random passoword which user is not aware/carn change.
大约 2 年之前 回复
csdnceshi78
程序go How to Set the token expiration to one week and refresh the token every time the user open the web application and every one hour. using node?
大约 2 年之前 回复
csdnceshi61
derek5. -1 Exposing a public API which blindly re-signs any token to extend its validation period is bad. Now all your tokens have an effective infinite expiry. The act of signing a token should include the appropriate auth checks for each and every claim made in that token at the time of signing.
2 年多之前 回复
csdnceshi65
larry*wei You said in the Web App example that it is best to "Set the token expiration to one week" - I can't figure out at all how to set the expiry of a refresh token - I thought they lasted forever unless they were revoked. I'm a bit confused! Thanks!
接近 3 年之前 回复
weixin_41568126
乱世@小熊 I agree. (In some services you cannot change your pw with just the token, but a pw change require the user to enter the pw again.) I meant a hash of the "salted and hashed pw"+scope+accountStatus just to avoid bugs about regenerating the random "refresh token" when these values changes. But to explicitly regenerate a random refresh token is a write similar solution.
接近 3 年之前 回复
weixin_41568196
撒拉嘿哟木头 I still think it's a good solution. I've talked to people who have been very uncomfortable with storing a hashed password in the token though. I'm not sure why exactly, since having the token means having the password (or being able to change it) during its validity period anyway. A safer option would be having a second, randomly generated "password" (similar to the refresh token idea) that's in the payload of the access token, that's what gets checked for validity on refresh. You'd change this "password" when user password changes, or when you revoke access for example.
接近 3 年之前 回复
weixin_41568183
零零乙 for web app, I don't think refresh the token before it expires solve any sercurity problem but increase complexity .compare with the JWT token with a short expire time it works the same way. using an unsecure token to get another unsecure token not make sence to me! Although I use Auth0...
大约 3 年之前 回复
weixin_41568126
乱世@小熊 Some time later, what did you end up with? I'm having the same thoughts as you for the same reasons. By putting a hash of the user PW and scopes in the Access token, this hash could be compared with the current values in the backend each time an Access Token expires. If these values are not changed, and the account is not locked, (and possibly, the Access Token is not in a blacklist), the expired Access Token is enough to issue a new Access Token. This makes the expiry time in an Access Token becomes a "heart beat" describing how often to validate a request towards the backend DB.
大约 3 年之前 回复
csdnceshi73
喵-见缝插针 But what if someone have refresh token which never expire? He will have access to your account forever?
3 年多之前 回复
weixin_41568196
撒拉嘿哟木头 I should have clarified that I'm trying to reach a solution where I don't persist a refresh token on the backend & rely purely on a client JWT, the reason is that I'm trying to allow the backend to scale horizontally without maintaining a common cache (i.e. a fully distributed system)
3 年多之前 回复
csdnceshi69
YaoRaoLov Your comment realizes the trouble with stolen devices, similar somehow to the logic when password changes. I believe if you already have the refresh token persisted on the server side, for validation when a token needs to be refreshed, there is no need to include in the token the hashed password as you would only simply need to delete all previous refresh tokens of the user after he changes is password. Also you get the benefit that in you backend the user can check all his opened sessions based on the refresh tokens and can invalidate. Like facebook, gmail does
3 年多之前 回复
weixin_41568196
撒拉嘿哟木头 Two questions/concerns: 1- Web Application case: why can't expired token be allowed to get a refresh? Say we set short expiration (1 hour) & make renew calls to the backend server when a token expires, as you said. 2- Is there a security concern with storing the hashed (with random salt) password in the token? The idea is that if it's there, the backend server can check against the stored password in the DB when asked for a renewal, & deny request if passwords don't match. This would cover the Mobile/Native app password change, allowing the solution to be extended to Mobile use case.
大约 4 年之前 回复
weixin_41568134
MAO-EYE Sorry for the confusion, I meant client-side in the browser, like local storage or a cookie.
大约 4 年之前 回复
csdnceshi64
游.程 I have the same question as Lo-Tan. If we are storing tokens in the database how is it different from the traditional web sessions?
大约 4 年之前 回复
csdnceshi62
csdnceshi62 In your web application example, everything makes sense to me except having to store the token. I thought the beauty of JWT was stateless authentication - meaning the web application does NOT have to store the token as it is signed. I would think the server could just check the validity of the token, make sure it's within the expiration period, and then issue a renewed JWT token. Could you please elaborate on this? Maybe I just don't understand JWTs enough yet.
大约 4 年之前 回复
csdnceshi68
local-host Also, to clarify...the refresh token you reference..is that meant to not expire in both web and mobile?
4 年多之前 回复
csdnceshi68
local-host when you discuss generating a random string and storing it. Could you elaborate? Do you mean you store in on the mobile device, or on the server? What happens if they get a hold of the name of the device, or this random string (assuming it is on client) Wouldn't this let them get around any tokens being revoked?
4 年多之前 回复
weixin_41568110
七度&光 Web app: if you don't like refreshing every hour or you want to try an alternative solution, you could make all API requests pass through a server-side proxy that stores in a persistent way the users' refresh tokens and intercepts the 401 responses and exchange tokens before logging the users out. Note that in this way the refresh tokens are not exposed to the client, and the users would experience the same authentication as in native apps
4 年多之前 回复
csdnceshi76
斗士狗 I used an angular interceptor to implement the refresh with each http request.
4 年多之前 回复
weixin_41568134
MAO-EYE I meant that the refresh token is not a JWT but an opaque token.
4 年多之前 回复
csdnceshi66
必承其重 | 欲带皇冠 Can you clarify what you mean by 'We believe that JWT is not useful for these use cases so we use a random generated string and we store it on our side.' Which use cases and what is the random string for?
4 年多之前 回复
weixin_41568134
MAO-EYE yes interception is an issue, even with cookies. You should use https.
接近 5 年之前 回复
csdnceshi57
perhaps? For the web applications recommended approach, if the token is valid for a week are we not concerned with someone intercepting the token and then being able to use it for such a long time? Disclaimer: I don't quite know what I'm talking about.
接近 5 年之前 回复

jwt-autorefresh

If you are using node (React / Redux / Universal JS) you can install npm i -S jwt-autorefresh.

This library schedules refresh of JWT tokens at a user calculated number of seconds prior to the access token expiring (based on the exp claim encoded in the token). It has an extensive test suite and checks for quite a few conditions to ensure any strange activity is accompanied by a descriptive message regarding misconfigurations from your environment.

Full example implementation

import autorefresh from 'jwt-autorefresh'

/** Events in your app that are triggered when your user becomes authorized or deauthorized. */
import { onAuthorize, onDeauthorize } from './events'

/** Your refresh token mechanism, returning a promise that resolves to the new access tokenFunction (library does not care about your method of persisting tokens) */
const refresh = () => {
  const init =  { method: 'POST'
                , headers: { 'Content-Type': `application/x-www-form-urlencoded` }
                , body: `refresh_token=${localStorage.refresh_token}&grant_type=refresh_token`
                }
  return fetch('/oauth/token', init)
    .then(res => res.json())
    .then(({ token_type, access_token, expires_in, refresh_token }) => {
      localStorage.access_token = access_token
      localStorage.refresh_token = refresh_token
      return access_token
    })
}

/** You supply a leadSeconds number or function that generates a number of seconds that the refresh should occur prior to the access token expiring */
const leadSeconds = () => {
  /** Generate random additional seconds (up to 30 in this case) to append to the lead time to ensure multiple clients dont schedule simultaneous refresh */
  const jitter = Math.floor(Math.random() * 30)

  /** Schedule autorefresh to occur 60 to 90 seconds prior to token expiration */
  return 60 + jitter
}

let start = autorefresh({ refresh, leadSeconds })
let cancel = () => {}
onAuthorize(access_token => {
  cancel()
  cancel = start(access_token)
})

onDeauthorize(() => cancel())

disclaimer: I am the maintainer

csdnceshi57
perhaps? Oh good to know, something didn't make sense but now it does. Thanks for the answer.
大约 3 年之前 回复
csdnceshi74
7*4 Yes, the decode is a client-only decode and should not be aware of the secret. The secret is used to sign the JWT token server-side to verify that your signature was used to generate the JWT originally and should never be used from the client. The magic of JWT is that its payload can be decoded client-side and the claims inside can be used to build your UI without the secret. The only thing jwt-autorefresh decodes it for is to extract the exp claim so it can determine how far out to schedule the next refresh.
大约 3 年之前 回复
csdnceshi57
perhaps? Question about this, I saw the decode function it uses. Does it assume the JWT can be decoded without using a secret? Does it work with JWT that were signed with a secret?
大约 3 年之前 回复

I actually implemented this in PHP using the Guzzle client to make a client library for the api, but the concept should work for other platforms.

Basically, I issue two tokens, a short (5 minute) one and a long one that expires after a week. The client library uses middleware to attempt one refresh of the short token if it receives a 401 response to some request. It will then try the original request again and if it was able to refresh gets the correct response, transparently to the user. If it failed, it will just send the 401 up to the user.

If the short token is expired, but still authentic and the long token is valid and authentic, it will refresh the short token using a special endpoint on the service that the long token authenticates (this is the only thing it can be used for). It will then use the short token to get a new long token, thereby extending it another week every time it refreshes the short token.

This approach also allows us to revoke access within at most 5 minutes, which is acceptable for our use without having to store a blacklist of tokens.

Late edit: Re-reading this months after it was fresh in my head, I should point out that you can revoke access when refreshing the short token because it gives an opportunity for more expensive calls (e.g. call to the database to see if the user has been banned) without paying for it on every single call to your service.

How about this approach:

  • For every client request, the server compares the expirationTime of the token with (currentTime - lastAccessTime)
  • If expirationTime < (currentTime - lastAccessedTime), it changes the last lastAccessedTime to currentTime.
  • In case of inactivity on the browser for a time duration exceeding expirationTime or in case the browser window was closed and the expirationTime > (currentTime - lastAccessedTime), and then the server can expire the token and ask the user to login again.

We don't require additional end point for refreshing the token in this case. Would appreciate any feedack.

weixin_41568126
乱世@小熊 In this case, where do you store lastAccessedTime? You have to do it on backend and per request, so it becomes a not desired stateful solution.
3 年多之前 回复
csdnceshi50
三生石@ Is it a good choice in this day, It's look pretty much easy for implementation.
3 年多之前 回复

An alternative solution for invalidating JWTs, without any additional secure storage on the backend, is to implement a new jwt_version integer column on the users table. If the user wishes to log out or expire existing tokens, they simply increment the jwt_version field.

When generating a new JWT, encode the jwt_version into the JWT payload, optionally incrementing the value beforehand if the new JWT should replace all others.

When validating the JWT, the jwt_version field is compared alongside the user_id and authorisation is granted only if it matches.

csdnceshi57
perhaps? Hey, that may not be a "problem" depending on your requirements, but you're right; this doesn't support per-device session management.
一年多之前 回复
csdnceshi80
胖鸭 This has problems with multiple devices. Essentially if you log out on one device, it logs out everywhere. Right?
一年多之前 回复

Good question- and there is wealth of information in the question itself.

The article Refresh Tokens: When to Use Them and How They Interact with JWTs gives a good idea for this scenario. Some points are:-

  • Refresh tokens carry the information necessary to get a new access token.
  • Refresh tokens can also expire but are rather long-lived.
  • Refresh tokens are usually subject to strict storage requirements to ensure they are not leaked.
  • They can also be blacklisted by the authorization server.

Also take a look at auth0/angular-jwt angularjs

For Web API. read Enable OAuth Refresh Tokens in AngularJS App using ASP .NET Web API 2, and Owin

I solved this problem by adding a variable in the token data:

softexp - I set this to 5 mins (300 seconds)

I set expiresIn option to my desired time before the user will be forced to login again. Mine is set to 30 minutes. This must be greater than the value of softexp.

When my client side app sends request to the server API (where token is required, eg. customer list page), the server checks whether the token submitted is still valid or not based on its original expiration (expiresIn) value. If it's not valid, server will respond with a status particular for this error, eg. INVALID_TOKEN.

If the token is still valid based on expiredIn value, but it already exceeded the softexp value, the server will respond with a separate status for this error, eg. EXPIRED_TOKEN:

(Math.floor(Date.now() / 1000) > decoded.softexp)

On the client side, if it received EXPIRED_TOKEN response, it should renew the token automatically by sending a renewal request to the server. This is transparent to the user and automatically being taken care of the client app.

The renewal method in the server must check if the token is still valid:

jwt.verify(token, secret, (err, decoded) => {})

The server will refuse to renew tokens if it failed the above method.

In the case where you handle the auth yourself (i.e don't use a provider like Auth0), the following may work:

  1. Issue JWT token with relatively short expiry, say 15min.
  2. Application checks token expiry date before any transaction requiring a token (token contains expiry date). If token has expired, then it first asks API to 'refresh' the token (this is done transparently to the UX).
  3. API gets token refresh request, but first checks user database to see if a 'reauth' flag has been set against that user profile (token can contain user id). If the flag is present, then the token refresh is denied, otherwise a new token is issued.
  4. Repeat.

The 'reauth' flag in the database backend would be set when, for example, the user has reset their password. The flag gets removed when the user logs in next time.

In addition, let's say you have a policy whereby a user must login at least once every 72hrs. In that case, your API token refresh logic would also check the user's last login date from the user database and deny/allow the token refresh on that basis.

csdnceshi72
谁还没个明天 so each time you are presumably query some User repository/db to check the last password change...
大约 2 年之前 回复
weixin_41568127
?yb? end user will have to re-login on every device unless his token is obtained by login session that used current password. So password change will lock the account on all computers.
大约 3 年之前 回复
weixin_41568183
零零乙 this is true. Remember that each token has a creation time, so one workaround would be to simply compare the password reset time with the token creation time - tokens created prior to the last password reset would not get renewed.
大约 3 年之前 回复
weixin_41568208
北城已荒凉 Very much a valid point! No only if an attacker is invloved. If you are logged in on multiple deviced, the end user will have a very odd behaviour. Having to re-login only on the first device after a password update... Let's say you logged in at a friends computer, or a computer at a internet Cafe, work school etc. You would expect a password change to lock the account on your those computers.
大约 3 年之前 回复
weixin_41568208
北城已荒凉 This is good unless you ever want to put in more triggers in your hash. Maybe a to force re-login when changing IP to the other side of the world in 1 second or something like that. Then if you change your algorithm for calculation the hash, all your users will need to re-login on the next BE invocation. One solution could be to store the hash in the DB and check agains that hash each time an Access Token needs to get renewed.
大约 3 年之前 回复
weixin_41568208
北城已荒凉 I think the other way around, if the password is changed, old expired tokens will still be valid. The first hit will require an reauthentication, but then successive calls will pass again. So the existing expired tokens will very much still be valid. Just like user2924127 mentioned.
大约 3 年之前 回复
csdnceshi75
衫裤跑路 I like this method, its kind a hybrid solution.
3 年多之前 回复
csdnceshi73
喵-见缝插针 I think the first comment by user2924127 is actually wrong. When the password is changed, the account is marked as requiring a re-authentication, so any existing expired tokens will be invalid.
3 年多之前 回复
weixin_41568127
?yb? I didn't suggest password hashing but to hash a string (can be modified_at, password or any data that should trigger logout) with a fast hashing function, let's say md5. Nowadays, doing md5(short_string) is not a performance issue. If you need to force "individual re logins", then reauth won't help here either.
3 年多之前 回复
csdnceshi77
狐狸.fox thinking of in optimizations and performance, I think the password hash validation would be redundant and have more server implications. Increase the size of the token so signature firm/validation takes more time. additional hash calculations for server for the password. with the extra field approach you just validate in the recalculation with a simple boolean. Db updates is less frequent for the extra field, but is more frequent token refreshes. And you get the optional service of force individual re logins for any existing session (mobile, web, etc).
3 年多之前 回复
weixin_41568127
?yb? instead of having another field in the database, reauth flag, you can include for hash(bcrypt_password_hash) in the token. Then when refreshing token, you just confirm if hash(bcrypt_password_hash) is equal to a value from the token. In order to deny token refresh, one has to just update password hash.
大约 4 年之前 回复
weixin_41568183
零零乙 no auth solution is perfect, and there will always be tradeoffs. If an attacker is in a position to 'steal your token', then you may have greater issues to worry about. Setting a maximum token lifetime would be a useful tweak to the above.
4 年多之前 回复
weixin_41568110
七度&光 I don't think this would be secure. If I was an attacker and stole your token and sent it to the server, the server would check and see the flag is set to true which is great as it would block a refresh. The problem I think would be if the victim changed their password the flag would be set to false and now the attacker can use that original token to refresh.
4 年多之前 回复

I was tinkering around when moving our applications to HTML5 with RESTful apis in the backend. The solution that I came up with was:

  1. Client is issued with a token with a session time of 30 mins (or whatever the usual server side session time) upon successful login.
  2. A client-side timer is created to call a service to renew the token before its expiring time. The new token will replace the existing in future calls.

As you can see, this reduces the frequent refresh token requests. If user closes the browser/app before the renew token call is triggered, the previous token will expire in time and user will have to re-login.

A more complicated strategy can be implemented to cater for user inactivity (e.g. neglected an opened browser tab). In that case, the renew token call should include the expected expiring time which should not exceed the defined session time. The application will have to keep track of the last user interaction accordingly.

I don't like the idea of setting long expiration hence this approach may not work well with native applications requiring less frequent authentication.

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
其他相关推荐
如何对jwt生成的token 实现验证(已经可以验证)、过期处理以及token刷新
-
H5项目中使用token(JWT)
-
jwt登录过期的问题求大佬指教
-
jwt token 放在请求头是安全的吗,浏览器的开发者工具是可以看到请求的token值的
-
java微服务使用的是springsecurity,oauth2,jwt认证授权,现在我的授权服务和资源服务没有分离,在一个服务中,请问怎么才能携带jwt令牌访问授权服务?求大佬解答,万分感谢
-
php laravel框架引入jwt,线上正常,下载本地报错?
-
JWT不会很耗费资源吗?
-
急:使用springsecurity+oauth2+jwt认证服务器和资源服务器在同一个服务中,jwt使用的非对称加密,应该怎么配置该模块?
-
用passport-jwt验证token时报错'JwtStrategy requires a function to retrieve jwt from requests '
-
axios 配合jwt过期后使用refreshToken 刷新token ,如何记录之前的请求并在刷新之后无缝发送这个请求
-
@Import导入类中的@Autowired无法导入
-
go beego 注解路由 添加 jwt校验
-
如何取得token里面的值呢
-
关于spring Security OAuth2 生成Token和Jwt的问题
-
cas和token鉴权有什么区别
-
请问Python已读取的CSV文件如何去掉Index值?
-
在loginactivity中用sharedpreference保存的用户信息,怎样在其他activity和fragment中读取
-
关于JWT token实现密码重置
-
spring oauth2(jwt)密码模式为什么还需要clientId,多个资源服务器为什么能用同一个token?
-
关于JWT Token的问题 如何保证接口安全性 不能被随意访问
-
学会了这些技术,你离BAT大厂不远了
每一个程序员都有一个梦想,梦想着能够进入阿里、腾讯、字节跳动、百度等一线互联网公司,由于身边的环境等原因,不知道 BAT 等一线互联网公司使用哪些技术?或者该如何去学习这些技术?或者我该去哪些获取这些技术资料?没关系,平头哥一站式服务,上面统统不是问题。平头哥整理了 BAT 等一线大厂的必备技能,并且帮你准备了对应的资料。对于整理出来的技术,如果你掌握的不牢固,那就赶快巩固,如果你还没有涉及,现在...
Linux文件操作高频使用命令
文章目录0.新建操作:1.查看操作2.删除操作3.复制操作4.移动操作:5.重命名操作:6.解压压缩操作 0.新建操作: mkdir abc #新建一个文件夹 touch abc.sh #新建一个文件 1.查看操作 查看目录: ll #显示目录文件详细信息 查看文件内容: cat|head|tail命令 cat abc.txt #查看abc的内容 head -5 abc.txt #...
程序员实用工具网站
目录 1、搜索引擎 2、PPT 3、图片操作 4、文件共享 5、应届生招聘 6、程序员面试题库 7、办公、开发软件 8、高清图片、视频素材网站 9、项目开源 10、算法 11、在线工具宝典大全 程序员开发需要具备良好的信息检索能力,为了备忘(收藏夹真是满了),将开发过程中常用的网站进行整理。 1、搜索引擎 1.1、秘迹搜索 一款无敌有良心、无敌安全的搜索引擎,不会收...
史上最详细的IDEA优雅整合Maven+SSM框架(详细思路+附带源码)
网上很多整合SSM博客文章并不能让初探ssm的同学思路完全的清晰,可以试着关掉整合教程,摇两下头骨,哈一大口气,就在万事具备的时候,开整,这个时候你可能思路全无 ~中招了咩~ ,还有一些同学依旧在使用eclipse或者Myeclipse开发,我想对这些朋友说IDEA 的编译速度很快,人生苦短,来不及解释了,直接上手idea吧。这篇文章每一步搭建过程都测试过了,应该不会有什么差错。本文章还有个比较优秀的特点,就是idea的使用,基本上关于idea的操作都算是比较详细的,所以不用太担心不会撸idea!最后,本文
全球最厉害的 14 位程序员!
来源 | ITWorld 整理自网络全球最厉害的 14 位程序员是谁?今天就让我们一起来了解一下吧,排名不分先后。01. Jon Skeet个人名望:程序技术问答网站 S...
我花了一夜用数据结构给女朋友写个H5走迷宫游戏
起因 又到深夜了,我按照以往在csdn和公众号写着数据结构!这占用了我大量的时间!我的超越妹妹严重缺乏陪伴而 怨气满满! 而女朋友时常埋怨,认为数据结构这么抽象难懂的东西没啥作用,常会问道:天天写这玩意,有啥作用。而我答道:能干事情多了,比如写个迷宫小游戏啥的! 当我码完字准备睡觉时:写不好别睡觉! 分析 如果用数据结构与算法造出东西来呢? ...
什么是大公司病(太形象了)
点击蓝色“五分钟学算法”关注我哟加个“星标”,天天中午 12:15,一起学算法作者 | 南之鱼来源 | 芝麻观点(chinamkt)所谓大企业病,一般都具有机构臃肿、多重...
让程序员崩溃的瞬间(非程序员勿入)
今天给大家带来点快乐,程序员才能看懂。 来源:https://zhuanlan.zhihu.com/p/47066521 1. 公司实习生找 Bug 2.在调试时,将断点设置在错误的位置 3.当我有一个很棒的调试想法时 4.偶然间看到自己多年前写的代码 5.当我第一次启动我的单元测试时 ...
Spring高级技术梳理
Spring高级技术梳理 序言正文SpringDate部分Spring全家桶之SpringData——预科阶段Spring全家桶之SpringData——Spring 整合Hibernate与Hibernate JpaSpring全家桶之SpringData——Spring Data JPASpring全家桶之SpringData——SpringData RedisSpringBoot部分Sp...
Git 天天用 但是 Git 原理你了解吗?
Git 原理 做技术一定要知其然知其所以然,意思就是:知道它是这样的,更知道它为什么是这样的。我主要通过4块内容来简单介绍 Git 是原理是什么样的。这4块内容如下: Git 存储目录结构介绍 Git 是如何存储的 Git 的对象 Git引用 当然 Git 原理不仅仅包含这些,想要更深入了解请查看官方教程 https://git-scm.com/book/zh/v2/。 本文内容是我在 Git...
分享靠写代码赚钱的一些门路
作者 mezod,译者 josephchang10如今,通过自己的代码去赚钱变得越来越简单,不过对很多人来说依然还是很难,因为他们不知道有哪些门路。今天给大家分享一个精彩...
对计算机专业来说学历真的重要吗?
我本科学校是渣渣二本,研究生学校是985,现在毕业五年,校招笔试、面试,社招面试参加了两年了,就我个人的经历来说下这个问题。 这篇文章很长,但绝对是精华,相信我,读完以后,你会知道学历不好的解决方案,记得帮我点赞哦。 先说结论,无论赞不赞同,它本质就是这样:对于技术类工作而言,学历五年以内非常重要,但有办法弥补。五年以后,不重要。 目录: 张雪峰讲述的事实 我看到的事实 为什么会这样 ...
技术人员要拿百万年薪,必须要经历这9个段位
很多人都问,技术人员如何成长,每个阶段又是怎样的,如何才能走出当前的迷茫,实现自我的突破。所以我结合我自己10多年的从业经验,总结了技术人员成长的9个段位,希望对大家的职...
8000字干货:那些很厉害的人是怎么构建知识体系的
本文约8000字,正常阅读需要15~20分钟。读完本文可以获得如下收益: 分辨知识和知识体系的差别 理解如何用八大问发现知识的连接点; 掌握致用类知识体系的构建方法; 能够应用甜蜜区模型找到特定领域来构建知识体系。 1. 知识体系?有必要吗? 小张准备通过跑步锻炼身体,可因为之前听说过小腿变粗、膝盖受伤、猝死等等与跑步有关的意外状况,有点担心自己会掉进各种坑里,就在微信上问朋友圈一直晒跑步...
nginx学习,看这一篇就够了:下载、安装。使用:正向代理、反向代理、负载均衡。常用命令和配置文件
文章目录前言一、nginx简介1. 什么是 nginx 和可以做什么事情2.Nginx 作为 web 服务器3. 正向代理4. 反向代理5. 动静分离6.动静分离二、Nginx 的安装三、 Nginx 的常用命令和配置文件四、 Nginx 配置实例 1 反向代理五、 Nginx 配置实例 2 负载均衡六、 Nginx 配置实例 3 动静分离七、 Nginx 的高可用集群 前言 一、nginx简介...
《漏洞篇》sql注入---入门到进阶
目录导航 sql注入的原理 sql注入的条件 sql注入的危害 sql注入的分类、验证及利用方式 sql数值型注入 sql注入的原理: 概述:针对SQL注入的攻击行为可描述为通过用户可控参数中注入SQL语法,破坏原有SQL结构,达到编写程序时意料之外结果的攻击行为,其本质就是对于输入检查不充分,导致SQL语句将用户提交的非法数据当作语句的一部分来执行,sql注入产生的原理有以下几个方面 程序编...
500行代码,教你用python写个微信飞机大战
这几天在重温微信小游戏的飞机大战,玩着玩着就在思考人生了,这飞机大战怎么就可以做的那么好,操作简单,简单上手。 帮助蹲厕族、YP族、饭圈女孩在无聊之余可以有一样东西让他们振作起来!让他们的左手 / 右手有节奏有韵律的朝着同一个方向来回移动起来! 这是史诗级的发明,是浓墨重彩的一笔,是…… 在一阵抽搐后,我结束了游戏,瞬时觉得一切都索然无味,正在我进入贤者模式时,突然想到,如果我可以让更多人已不同的方式体会到这种美轮美奂的感觉岂不美哉? 所以我打开电脑,创建了一个 `plan_game.py`……
2019诺贝尔经济学奖得主:贫穷的本质是什么?
2019年诺贝尔经济学奖,颁给了来自麻省理工学院的 阿巴希·巴纳吉(Abhijit Vinayak Banerjee)、艾丝特·杜芙若(Esther Duflo)夫妇和哈...
别在学习框架了,那些让你起飞的计算机基础知识。
我之前里的文章,写的大部分都是与计算机基础知识相关的,这些基础知识,就像我们的内功,如果在未来想要走的更远,这些内功是必须要修炼的。框架千变万化,而这些通用的底层知识,却是几乎不变的,了解了这些知识,可以帮助我们更快着学习一门知识,更加懂得计算机的运行机制。当然,在面试中也经常会被问到,特别是对于应届生,对于春秋招,也可以看看我前阵子写过的文章历经两个月,我的秋招之路结束了!。也有读者经常问的计算...
MySQL数据库—SQL汇总
一、准备 下文整理常见SQL语句的用法,使用MySQL5.7测试,参考了尚硅谷MySQL教程及用例。用例sql: 链接: https://pan.baidu.com/s/1tb3-12MRNFjV8drFlN6wzg&amp;shfl=sharepset 密码: fc2h 为了方便查阅可从右侧目录快速索引 二、DQL(Data Query Language)数据查询语言 1、语句顺序 书写顺序...
相关热词 c#部署端口监听项目、 c#接口中的属性使用方法 c# 昨天 c#func链接匿名方法 c#怎么创建文件夹 c#从键盘接收空格 c#da/ad c#部门请假管理系统 c#服务器socket c# 默认的访问修饰符